LabVIEW
.NET library loaded in LabVIEW 2019 does not use system default TLS version
Solved!
hi,
Could you confirm the "appcontext" has the constructor classes enabled/available for you? they are not available/exposed to me , (wondering is the organization policy has something to do with this?)
I used Invoke Node (.NET), right clicked on it -> Select Class -> .NET -> Browse -> mscorlib(4.0.0.0) -> System -> AppContext. Then right click on the Invoke Node again -> Select Method -> [S]SetSwitch.
@tst wrote:
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).
It's a miracle :-).
The actual explanation is that the .Net team repeatedly has restructured the .Net class hierarchy. They did create aliases for old locations that the MS Tools such as Visual Studio somehow can resolve when used in the import statement. But LabVIEWs type library parser uses the explicit class hierarchy in the type library and doesn't seem to care about those alias statements normally. (And that is maybe not a bad thing, the class hierarchy presented in the list box would be getting otherwise even more lengthy and complex than it already is).
LabVIEWs .Net interface works opposite to how you would access .Net APIs in C#. In C# you add import statements that the compiler then will resolve. If the import statement specifies an aliased name then the compiler will resolve it to the real location.
In LabVIEW you browse the class hierarchy and point it at the desired class. And that class hierarchy isn't always (well quite often) very concise and straightforward. And the actual location doesn't always match with what the .Net documentation states as canonical class path.
So Visual programming environments like LabVIEW, Visual Basic or Delphi that provide the class hierarchy as a browsable hierarchy are in a different situation than when you program in C# where you have to know the classpath to put in the import statement. There are likely some (involved) solutions to that problem that would allow a more concise and understandable representation of the class hierarchy in a browsable way, but the .Net functionality in LabVIEW has been developed some 20 years ago when .Net was in its infancy and these basic parts of the .Net interface in LabVIEW have undergone mostly minor improvements and definitely haven't been fully re-implemented from scratch. It is also unlikely that this is ever going to happen from now on, unless something in the LabVIEW development process is going to change very fundamentally.
Hi
Can i get some more information on this with the below questions
1> How do i know which version of .net is used by LabVIEW (2019) when a ".net dll" is used.
Even though the listed version is shown as 4.0.0.0, how do i know that LabVIEW is actually using the latest version (in my case its of the .net installed and not some thing else.
The powershell command shows it as "4.8.04084"
I am asking these questions based on the article <https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls> to ensure the code I distribute, makes use of latest version of the ".net framework" for the ".net dll"
@Guruguruthilak.kamata wrote:1> How do i know which version of .net is used by LabVIEW (2019) when a ".net dll" is used.
View>.NET Assemblies in Memory shows a list.
If you want to get the list from your application, use "\LabVIEW 2019\vi.lib\DotNET\AssemblyVisualizationTool\GetArrayOfAssemblyInfo.vi" (used by .NET Assemblies in Memory).
.NET Reflection has tools for that too, but it does a lot more so it might be a bit of a puzzle to get exactly what you're looking for.
Search LabVIEW like a graph!
"View>.NET Assemblies" shows a list of the "Target CLR" (with other info), but never shows the which version of the ".net framework" is loaded. This is becoming a mystery for me.
Is there any way to find this out.
