11-16-2021 05:30 AM
Hello,
many of our LabVIEW components are based on .NET DLLs.
Now over time, multiple different versions of these DLLs were implemented, which may not all be compatible.
So example:
VI A implements Version 1 of the DLL and VI B implements Version 2 of the DLL.
The different DLL versions are located in different directories.
Upon opening VI A, you will see the popup "the version of the assembly you requested was automatically promoted to a later version by the .net runtime engine" and the VI will be broken due to incompatibility of DLL Version 2.
When you get around it by programming both VIs separately or using 2 wrapper DLLs which implement Version 1 / Version 2 of the original DLL, at runtime only one version will be loaded so only one of the VIs will get executed correctly and the other one will throw an error.
Also using different application instances by putting VI A and VI B in separate LV Projects does not fix the issue.
Is there any way to load and run multiple versions of the same .NET DLL in the same LabVIEW / Teststand application?
Stefan
Solved! Go to Solution.
11-16-2021 07:08 AM
Found the solution.
The issue was fixed after not only putting the calling VIs into separate LV Projects, but also putting the DLLs in a directory far away from the LabVIEW application.
Not sure why that is the case though, so if anybody can shed some light into the process of how LabVIEW loads DLLs and how it decides which DLL is appropriate, it would be very welcome.
11-16-2021 12:42 PM
Have you seen this? https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAm6SAG&l=en-NZ
Besides adding some custom probe paths as described in that link, LabVIEW inherits the same rules as all other CLR hosts, since its the .NET CLR Loader that handles finding appropriate referenced assemblies. Take a look at some of the external links there.