在 .NET Framework 时代里面，有一组有趣的概念，那就是 SDK 和 Runtime 这两个概念。开发模式十分有趣，在开发者设备上，可以指定 .NET Framework 的 SDK 版本，例如指定 .NET Framework 4.5 版本。开发完成之后，分发给到用户，用户的电脑上所安装的 .NET Framework 基本都是 Runtime 版本。应用程序要求运行的 Runtime 版本一定要大于等于 SDK 的指定版本号

这就有一个非常有趣的问题了，我开发环境使用的 SDK 是低版本，例如 .NET Framework 4.5 版本。但用户的电脑上所安装的 .NET Framework 的 Runtime 版本是高版本，例如是 .NET Framework 4.7 版本，中间距离过了几年的版本。那行为如何保证相同？如果行为不能保证相同，那将会出现行为差异，在我的开发设备上跑得好好的，在一些用户电脑上，将会因为运行时基础库的版本差异从而变更行为，应用程序就不能符合预期跑起来了。事实上，咱没有碰到过这个问题，这是因为在 .NET Framework 层做了很多兼容处理逻辑，其中就包括本文要和大家聊的 WPF 框架的兼容行为

本文所聊的仅仅只是 .NET Framework 的老故事，本文对 .NET Core 3.0 及以上版本基本无效，因为其开发模式变更了

在 .NET Framework 的开发模式里面，开发者采用的是 .NET Framework SDK 进行开发，可以指定版本号。指定版本号后，生成的应用程序要求在运行的设备上，一定要安装大于或等于指定版本的运行时才可以

在 .NET Framework 下，无法让 .NET Framework 的运行时跟随应用进行分发，应用只能采用系统里安装的版本。存在的问题就是应用在开发阶段是无法预知实际运行在用户端，用户的设备上所安装的 .NET Framework 版本的

如果对于相同的一套代码，在不同的 .NET Framework 版本下，有行为上的差异，那这是一个非常可怕的事情，甚至开发端啥都做不了。想想如以下的例子，假如我是 .NET Framework 版本的 WPF 框架的开发者，我写了一个叫 Foo 的方法，这个方法我是在 .NET Framework 4.5 定义的，用于支持某个关键逻辑。但是我在 .NET Framework 4.6 版本，我觉得这个方法应该抛出异常，于是就让这个 Foo 方法被调用时一定抛出异常

这个时候，预计开发者将会寄刀片给我。因为开发者将会发现他的应用能在一些用户的设备上，符合预期工作。在一些用户的设备上，一定会炸掉。其原因就是我在高版本上变更了行为。根本原因就是开发者无法独立分发 .NET Framework 导致应用程序的运行受实际的环境影响

当然了，这个问题在 .NET Core 或 .NET 下已经被彻底解决，那就是允许开发者自己独立发布，不依赖系统的 .NET 环境。如此的开发模式，既可以降低基础运行时框架开发者的压力，也能让上层应用业务端的开发者能更好的控制应用运行，减少奇怪的环境问题

作为考古的博客，继续回到主题

在实际的开发里面，几乎没有遇到上面说的由于 .NET Framework 的 Runtime 版本不同，而导致的行为不同从而导致的问题

这是因为在 WPF 里面做了很多的兼容的处理逻辑。例如大家都知道的，在 .NET Framework 4.0 到 .NET Framework 4.5 是存在极大的变动的。在 WPF 里面，为了编写代码方便，就添加了一个叫 FrameworkCompatibilityPreferences 的类型，里面有一个属性如下

    public static class FrameworkCompatibilityPreferences
    {
        static FrameworkCompatibilityPreferences()
        {
#if NETFX && !NETCOREAPP
            _targetsDesktop_V4_0 = BinaryCompatibility.AppWasBuiltForFramework == TargetFrameworkId.NetFramework
                && !BinaryCompatibility.TargetsAtLeast_Desktop_V4_5;
#elif NETCOREAPP
            // When building for NETCOREAPP, set this to false
            // to indicate that quirks should be treated as if they are running on 
            // .NET 4.5+
            _targetsDesktop_V4_0 = false;
#else
            _targetsDesktop_V4_0 = false;
#endif
        }

        // CLR's BinaryCompatibility class doesn't expose a convenient way to determine
        // if the app targets 4.0 exactly.  We use that a lot, so encapsulate it here
        static bool _targetsDesktop_V4_0;

        internal static bool TargetsDesktop_V4_0
        {
            get { return _targetsDesktop_V4_0; }
        }
    }

在各处代码里面对此属性的判断，从而加上兼容的逻辑，例如绑定的代码

    public class Binding : BindingBase
    {
        public PropertyPath Path
        {
            get { return _ppath; }
            set
            {
                _ppath = value;

                if (_ppath != null && _ppath.StartsWithStaticProperty)
                {
                    if (_sourceInUse == SourceProperties.None || _sourceInUse == SourceProperties.StaticSource 
                    	// 在 .NET Framework 4.5 和以上的版本更改了行为，需要加上兼容逻辑
                    	|| FrameworkCompatibilityPreferences.TargetsDesktop_V4_0) 
                    {
                        // net 4.5 breaks static bindings - this is for compat
                        SourceReference = StaticSourceRef;
                    }
                    else
                        throw new InvalidOperationException(SR.Get(SRID.BindingConflict, SourceProperties.StaticSource, _sourceInUse));
                }
            }
        }
    }

毫无疑问，通过一个属性的方式确实简单明了。缺点也很明显，代码里面将会充斥版本判断逻辑，这个方式是走不远的。这个也算是兼容的包袱

作为一群对代码有追求的开发者，肯定是要做一些设计。于是大家可以看到 WPF 开源仓库里面，实际上现在主流的还有一层兼容逻辑，那就是功能开关

依托 System.AppContext 提供的组件之间建立松耦合的协定，从而将代码里面原本对版本强依赖的逻辑变更为对功能的支持

这是一个很好的思路，让功能的开关与具体的 .NET Framework 版本关联，让实际的功能逻辑和功能开关关联。如此即可进行逻辑控制且减少在代码里面判断版本的逻辑，也不会在后续随着版本越来越多，维护越来越难

另外，功能开关本身和具体的 .NET Framework 版本只是一个弱相关性而已，仅仅只是在应用程序运行的时候，在应用程序配置里面声明这个应用程序所期望运行的 .NET Framework 版本，再根据此声明使用的版本，决定开关的开启和关闭

例如在 AppContextDefaultValues 里的代码

    internal static partial class AppContextDefaultValues
    {
        static partial void PopulateDefaultValuesPartial(string platformIdentifier, string profile, int targetFrameworkVersion)
        {
            switch (platformIdentifier)
            {
                case ".NETFramework":
                    {
                        if (targetFrameworkVersion <= 40601)
                        {
                            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.DoNotScaleForDpiChangesSwitchName, true);
                        }

                        if (targetFrameworkVersion <= 40602)
                        {
                            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.OverrideExceptionWithNullReferenceExceptionName, true);
                        }

                        if (targetFrameworkVersion <= 40702)
                        {
                            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.DoNotUsePresentationDpiCapabilityTier2OrGreaterSwitchName, true);
                        }

                        break;
                    }
                case ".NETCoreApp":
                    {
                        InitializeNetFxSwitchDefaultsForNetCoreRuntime();
                    }
                    break;
            }
        }

        private static void InitializeNetFxSwitchDefaultsForNetCoreRuntime()
        {
            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.DoNotScaleForDpiChangesSwitchName, false);
            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.OverrideExceptionWithNullReferenceExceptionName, false);
            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.DoNotUsePresentationDpiCapabilityTier2OrGreaterSwitchName, false);

            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.DisableStylusAndTouchSupportSwitchName, false);
            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.EnablePointerSupportSwitchName, false);
            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.DisableDiagnosticsSwitchName, false);
            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.AllowChangesDuringVisualTreeChangedSwitchName, false);
            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.DisableImplicitTouchKeyboardInvocationSwitchName, false);
            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.ShouldRenderEvenWhenNoDisplayDevicesAreAvailableSwitchName, false);
            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.ShouldNotRenderInNonInteractiveWindowStationSwitchName, false);
            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.DoNotUsePresentationDpiCapabilityTier3OrGreaterSwitchName, false);
            LocalAppContext.DefineSwitchDefault(CoreAppContextSwitches.AllowExternalProcessToBlockAccessToTemporaryFilesSwitchName, false);
        }
    }

当然，功能开关的作用可不只是用来做兼容逻辑，还可以用来实现特殊的配置，从而打开某些功能或者禁用某些功能，更方便开发者进行定制。更多的功能开关请看 WPF Application Compatibility switches list

这就是 WPF 框架对 .NET Framework 运行时版本不同进行的适配逻辑，通过在代码里面添加大量的判断条件，从而让开发者指定的运行版本和实际运行所采用的逻辑尽可能相同。这个兼容逻辑是 WPF 参考里面写代码实现的，也就是靠 WPF 框架的开发者保证的，这也就是本文开头我用了 几乎 而不是确定词来说不会在这里踩坑