LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2014 support for TLS 1.2 security level

Solved!
Go to solution
Highlighted

Hi,

We are trying to develop TLS 1.2 support with LabVIEW 2014 application using a .net DLL built in 4.6 framework,

However, the result is not positive.

We are getting response as "The requested security protocol is not supported."

 

The same DLL works fine with TLS 1.0 security level.

 

We are using URL link, username and password to ping the remote server (which is configured at TLS 1.2).

Below is our configuration

1. LabVIEW 2014 SP1

2. MeasurementStudio version 2010 (installed) for .Net

3. .Net DLL for webservice communication , built in >net Framework 4.6

 

We are using Constructor Node (in .Net function library ) to make the call.

Please advise if any additional setting is required or we are missing anything,

 

Query:

1. any specific configuration or setting for TLS 1.2 support with LabVIEW 2014 using .Net DLL built in 4.6 .Net Framework.

 

Thank You. 

0 Kudos
Message 1 of 8
(1,861 Views)
Highlighted

So the .net code inside a (c#?) dll is not working? I'd search a .net or c# forum.

 

It's only LabVIEW related if a) the dll is working outside LabVIEW or b) the firewall blocks LabVIEW.

 

0 Kudos
Message 2 of 8
(1,825 Views)
Highlighted

Hi,

the dll is working outside labview in Visual Studio environment. built using .net framework 4.6.

but when we call it through LabVIEW using the .Net constructor node, it fails. We get- "The requested security level is not supported".

 

 

0 Kudos
Message 3 of 8
(1,813 Views)
Highlighted

You will need to debug the DLL in Visual Studio while it runs under LabVIEW to see why it doesn't want to support TLS 1.2 in that situation. LabVIEW certainly is not on purpose preventing your assembly from doing that, but something in your assembly makes assumptions that are not quite true when it runs under LabVIEW 2014. At least it shouldn't be that LabVIEW loads by default with an CLR version below .Net 4.0 as LabVIEW uses by default 4.0 or higher since version 2013 unless you create a manifest file to tell it to start up with a lower version of the CLR.

Rolf Kalbermatter
Averna BV
Message 4 of 8
(1,804 Views)
Highlighted

Hi,

Update on the above issue: With some modifications in the .Net code we are getting desired response from exe and not VI.

 

Initially we were running the VI from a LV project and DLL was place inside a folder called data .

We get the response: "The request was aborted: Could not create SSL/TLS secure channel."

 

Later built an exe & installer and placed the dll inside the support directory created by labview (i.e. into data folder). Using the application (exe) we get the desired response..

 

With this, we would like to know where should we place the DLL while running through a vi inside a project.

This is only happening with DLL with TLS 1.2 support.

 

Previous version DLL are being loaded successfully with desired response when placed inside any folder within the labview project

0 Kudos
Message 5 of 8
(1,787 Views)
Highlighted

That you have to ask the developer of the DL!. LabVIEW has nothing to do with how a DLL tries to discover possible secondary DLLs. If the DLL doesn't do anything special but simply tries to load an assembly then the normal Windows search algorithm comes into play. Here Windows will first look in the directory of where the executable is located that started the current process (eg. LabVIEW.exe for the LabVIEW IDE, yourApp.exe for your build application). If that doesn't give a valid DLL load, Windows will search in the app domain for the current process. This is normally empty but an application can register directories to add to the app domain and LabVIEW does that with the directory where a project is located when you run a VI from within a project file.

Last but not least Windows will search in the GAC for the assembly.

In your build application LabVIEW most likely adds the data directory to the app domain search path since you have also a directly referenced .Net assembly in there. If you add your secondary DLLs into the same folder as your project file it should actually work.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 6 of 8
(1,778 Views)
Highlighted
Solution
Accepted by topic author Pankaj_K.

Hi,

Some modifications related to TLS 1.2 support were added in DLL source code

Line added:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
but then it was observed that since .Net FM was 4.6, such a line is no required, as .Net FM 4.6 and above has default support for TLS 1.2
Also

We placed the DLL in the directory where labview project is located.

For application, it was placed in data directory,

 

Issue resolved.

 

Thank you for the support.

 

 

0 Kudos
Message 7 of 8
(1,758 Views)
Highlighted

where can i find the example vi?

0 Kudos
Message 8 of 8
(540 Views)