.NET library loaded in LabVIEW 2019 does not use system default TLS version

[Nesh]

We have a .NET library which is used by LabVIEW 2019 among other things. Several methods in this library makes http calls to a server. Recently the server has disabled TLS 1.0 and 1.1, so communication with the server has to use TLS 1.2.

The .NET library targets .NET Framework 4.6.2, which supports using system default TLS version by default (i.e. you don't have to set the registry key SystemDefaultTlsVersions to 1). On Windows 8.1 and Windows 10, TLS 1.2 is the system default, so the .NET library uses TLS 1.2 by default. Good.

However, that does not seem to be the case when the library is loaded through LabVIEW 2019. In order for the library to use the system default TLS version when loaded in LabVIEW, I have to set either of these registry keys to 1 (depending on the bitness of LabVIEW):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SystemDefaultTlsVersions

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\SystemDefaultTlsVersions

Does anyone have any idea why this is the case? Is there anything I could do to the .NET library where I would not have to set these keys and still use the system default TLS version?

[wiebe@CARYA]

It's first make sure LabVIEW is using the .NET version you're expecting:

I seem to have 4.8 installed*, but LabVIEW uses 4.0.

*how-quickly-check-net-framework-version-windows-10

[Nesh]

Thank you for taking an interest.

I also seem to have .NET Framework 4.8 installed. System.Environment.Version gives the CLR version (which is 4.0.30319.42000 for me) not .NET version.

According to this https://docs.microsoft.com/en-us/dotnet/api/system.environment.version

---

 For the .NET Framework 4.6 and later versions, it has the form 4.0.30319.42000

---

[wiebe@CARYA]

Interesting... 

According to how-to-determine-which-versions-are-installed:

CLR version greater than or equal to 4.0.30319.42000 supports .NET Framework versions starting with .NET Framework 4.6.

So, back to 0 on the reason why your code acts weirdly...

[wiebe@CARYA]

EDIT: That posted it 2X...

[wiebe@CARYA]

Maybe this helps... Apparently, you can set the security protocol:

https://docs.microsoft.com/en-us/dotnet/api/system.net.securityprotocoltype?view=netcore-3.1

Perhaps LabVIEW sets the security protocol internally?

Perhaps you can set it instead of the registry key?

If you read it, maybe it will shed some light on the issue?

It's not a perfect match, I don't see why the registry key would help even if LabVIEW changes the protocol. So even if it helps, it won't explain anything.

[wiebe@CARYA · Accepted solution]

This one is interesting too:

https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls

For .NET Framework 4.6 - 4.6.2 and not WCF
Set the DontEnableSystemDefaultTlsVersions AppContext switch to false. See Configuring security via AppContext switches.

It seems pretty complicated to me...

[Nesh]

If I set the AppContext switch Switch.System.Net.DontEnableSystemDefaultTlsVersions to false before running the rest of the code it works!

Thanks

[Guruguruthilak.kamata]

Hi,

I am unable to locate this particular "appcontext" functionality (and hence the DontEnableSystemDefaultTlsVersions).

Where is this located? I am using Windows 10 (64bit) and LabVIEW 2019(32bit)

[tst]

---

@Guruguruthilak.kamata wrote:

Hi,

I am unable to locate this particular "appcontext" functionality (and hence the DontEnableSystemDefaultTlsVersions).

Where is this located? I am using Windows 10 (64bit) and LabVIEW 2019(32bit)

---

I don't know specifically about the TLS issue, but with .NET, sometimes you have to hunt around to find the specific class in LV. In my case, I can find the AppContext class by going to the mscorlib assembly (where you will often find these system classes) and looking under System (why not directly in the main list or in System.Runtime, which also exists in mscorlib? I have no idea. I never understood exactly how to figure out where the relevant class would show up).