CLR类库中ServicePointManager未初始化？TLS配置相关疑问

核心问题拆解与解答 #

1. 类库中的函数是否会导致安全协议未被初始化？ #

不会。类库本身不会阻碍安全协议的初始化，问题根源在于宿主进程的初始化方式。当原生C++程序通过CLR宿主加载.NET类库时，CLR的初始化流程和纯托管应用存在差异：纯托管应用启动时，.NET Framework会自动完成包括安全协议默认值配置在内的全局初始化；但原生宿主加载CLR时，部分默认初始化步骤不会自动触发，导致ServicePointManager.SecurityProtocol停留在.NET Framework早期版本的默认值（Ssl3|Tls）。

2. 此场景下是否必须显式设置ServicePointManager.SecurityProtocol属性？ #

是的，在原生C++托管你的.NET类库的场景下必须显式设置。因为原生宿主不会触发.NET Framework针对安全协议的默认初始化逻辑，不手动设置的话，程序会一直使用过时的协议版本，无法连接Azure表存储这类要求现代TLS的服务。

3. 是否托管应用会触发.NET Framework的初始化流程，而类库不会？ #

准确来说，是托管应用的启动入口会触发完整的.NET Framework全局初始化流程，而类库作为被加载的模块，本身不负责启动CLR的初始化。纯托管应用（比如控制台程序）的Main方法执行前，.NET运行时会完成全局初始化，包括将ServicePointManager.SecurityProtocol设置为SystemDefault；但原生C++程序是通过CLR宿主API（如CorBindToRuntimeEx）自行加载CLR，此时默认不会自动执行这些全局初始化步骤，需要类库自行补充设置。

4. 将其设置为Tls12是否可能破坏依赖Tls11的旧代码或要求Tls13的未来代码？ #

• 对于依赖Tls11的旧代码：如果类库还有其他调用依赖Tls11的服务，显式设置为Tls12会导致这些调用失败。这种情况下，可将值设置为Tls11 | Tls12，同时兼容两个版本。
• 对于要求Tls13的未来代码：.NET Framework 4.7.2本身不支持Tls13（Tls13在.NET Framework 4.8及以上版本才支持），所以即便不限制协议版本，在4.7.2环境下也无法使用Tls13。如果未来升级到支持Tls13的.NET版本，显式设置Tls12会限制程序使用Tls13，此时应改为设置为SystemDefault，让系统自动选择支持的最高协议版本。

补充建议：如果场景允许，优先将ServicePointManager.SecurityProtocol设置为SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11（需兼容旧服务时），或在确认所有服务都支持Tls12+时设置为Tls12。未来升级到.NET Framework 4.8及以上版本后，改为使用SystemDefault，让系统自动适配最新TLS协议。

内容的提问来源于stack exchange，提问作者Eleco Martin