Revit插件兼容2022版本升级策略（1） —背景

一、背景

       我们考虑兼容，其实是在做这样一件事：以应用级别源代码能够复用为目标，适应多个版本Revit提供的API的变化。

        我们要适应多个Revit的API谈不上向前兼容向后兼容的概念。我们只是在以复用为前提，去做多个版本库Dll的适配。

       在以往Revit插件适应新的Revit宿主版本的时候，我们的工作就是找到那些语义和功能一致，但是签名发生变化的那些函数，然后去适配这些函数，重新定义一个满足现有输入输出要求的新函数。常用做法就是做一个专门提供适配的项目，在这个项目中去兼容各个版本的差异，通过条件编译来控制具体的执行逻辑。更具体的实现就是定义一个静态类，把冲突方法规整成新的静态方法，然后在插件开发中，统一使用这个适配项目提供的封装过的方法。我们可以把这个模块理解成适配器，或者外观模式，或者代理，它仅仅是实现了隐式的调用子系统方案。

        例如如下实现：

public static class RevitAdapterAPI
{
        /// <summary>
        /// 获取填充区域类型的颜色，19中分为了前景颜色和背景颜色
        /// </summary>
        /// <param name="frType"></param>
        /// <returns></returns>
        public static void SetFilledRegionTypeColor(FilledRegionType frType, Color clr)
        {
#if R16 || R18
            frType.Color = clr;
#else
            frType.ForegroundPatternColor = clr;
#endif
        }
}

       这是一个渐进式的增量过程。由于两个Revit版本之间API差别有限,且在插件开发中基本也不会大范围的去使用这些特殊的功能，所以客观要求开发人员去有意识的使用那些适配过的方法也并非什么强人其难的事。

       但是，这次新的2022版本API改动有些特别，它引入的冲突不只是函数冲突那么简单，它还改动了一些更基础的东西，这些东西恰恰又是在插件开发中普遍使用，程序员已经形成普遍认知的东西，比如说单位的枚举，参数的枚举等等。它把这些枚举类型给变了，变成什么我们暂时先不细说，但像这种类型替代引起的变化，对设计兼容方案来说是非常不友好的。它不仅冲击了程序开发人员的思想认知，也会增加旧代码的改动量，这又变相的增加了出错的风险和测试的成本。

      所以，Revit2022版本的升级兼容不得不审慎的对待。

       

     接下来如果有时间，会继续更新如何实现这次版本升级.....