0

I've inherited a CLR class library (.NET Framework 4.7.2) that provides a function which queries table storage in Azure. The function, called from a native C++ executable, is currently failing because the TLS settings are insufficient.

If I query what the ServicePointManager.SecurityProtocol property is set to at the start of the function, I find it set to SSl3|Tls (both deprecated!). I have to explicitly set it to Tls12 to get the function to work.

If, instead, I create a new CLR console app project (also Framework 4.7.2) and add a function which simply queries the security protocol, I find it's set to SystemDefault.

Would I be right in thinking that having the function in a class library prevents the security protocol being initialised? Must I explicitly set the ServicePointManager.SecurityProtocol property in this scenario? Presumably .NET Framework is performing some initialisation when the app is managed, but not in the case of a class library. If true, can anyone expand on this a little?

Also, by setting it to Tls12 am I potentially breaking other calling code, e.g. old code which is happy with Tls11, or future code which insists on Tls13?

Eleco Martin
  • 59
  • 2
  • Someone is probably manually setting `ServicePointManager.SecurityProtocol` somewhere. No you should never set it manually, unless on .Net 4.5 or earlier. If that library is doing so then it should be changed. – Charlieface Jun 19 '23 at 13:54
  • The behavior of this property has changed, starting with .NET 4.7. SystemDefault is now the normal default. In other words, with your Console mode project it now knows that you targeted 4.7, in your old class library project it didn't. This info is carried by the [assembly: TargetFramework] attribute. It gets auto-generated in a complicated way as part of the build process, msbuild creates a small text file stored in the TEMP directory with the attribute. It gets compiled as a normal C++ source file. Apparently that didn't happen. Look at the detailed msbuild trace for hints. – Hans Passant Jun 19 '23 at 15:32
  • 2
    I just checked, it looks at the Assembly.GetEntryAssembly() for the attribute. Problem is, with the native C++ code being the effective entrypoint, that method returns null. So won't find the attribute, what you saw is the expected outcome. Consider assigning it yourself. – Hans Passant Jun 19 '23 at 15:41

0 Answers0