.NET Framework版本、VS目标框架与C#编译器协作机制疑问

这是个非常戳中.NET开发痛点的问题——哪怕是有多年经验的开发者，也容易在目标框架、编译器校验和运行时加载的关系上产生混淆，尤其是碰到.NET Framework这种「就地更新」的特性时。我来一步步拆解清楚：

核心真相：编译器靠「参考程序集」判断API可用性，而非系统里的实际DLL #

你之所以困惑，本质是混淆了编译阶段的API检查逻辑和运行阶段的实际DLL加载逻辑：

• 当你在Visual Studio中选定目标框架（比如.NET 4.5）时，编译器并不会直接用系统里已安装的System.dll做API校验。它会调用一套专门的参考程序集（Reference Assemblies）——这是微软为每个.NET Framework版本单独提供的「签名骨架」DLL，只包含API的定义（比如枚举成员、类结构），没有实际运行代码。
• 对于.NET 4.5的参考程序集来说，System.Net.SecurityProtocolType枚举里确实没有SystemDefault成员；而.NET 4.7的参考程序集才新增了这个定义。所以编译器会严格按照你选定的目标框架参考程序集检查代码，发现SystemDefault不在4.5的API契约里，就会抛出编译错误——这完全符合设计预期。

为什么运行时能拿到SystemDefault？因为运行时用的是系统最新的DLL #

你提到的「.NET 4.7是.NET 4.5的就地更新」是关键：

• 安装高版本.NET Framework时，系统里的核心运行时DLL（比如System.dll）会被替换成高版本的实现。所以当你的目标框架为4.5的程序运行时，CLR会加载系统中当前存在的最新System.dll（也就是4.7版本的），自然能通过Enum.GetValues枚举到SystemDefault成员。
• 但要注意：这种「运行时能访问到目标框架没有定义的API」属于非官方兼容场景，微软并不保证所有高版本新增API都能被低版本目标程序调用，可能存在潜在的兼容性风险（比如某些API的底层依赖在低版本目标框架中不存在）。

一句话总结区别 #

• 编译阶段：看目标框架的参考程序集，确保代码符合目标版本的API契约，避免写出在目标环境下理论上无法运行的代码。
• 运行阶段：看系统中已安装的最新.NET Framework运行时，实际执行用的是最新的DLL实现。

内容的提问来源于stack exchange，提问作者Sebastian Krysmanski