LabVIEW
How to update .NET dll in Dependencies
Solved!
Most of the time nothing, as soon as the prototypes of your dll functions did not change.
In practice, if you changed some of the prototypes (function name, parameters, return type…), LabVIEW may not be able to automatically update everything for you, so you may have broken VIs where you need to manually reselect the methods and properties.
Note 1 : To make the update, you first need to close the project, update your dll on disk, and then re-open your project, because LabVIEW locks the dll on disk when the project is loaded.
Note 2 : If your .NET dll comes from an Internet download, Windows may have locked it for security, which will give you a loading error when loading the assembly. So you either have to manually unlock the dlls or add a config file to allow the application to load locked dlls (see the following link for more details https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8XnSAK&l=fr-FR)
It depends! (as always )😀
.Net only knows two default locations where it will search for .Net components when an application requests to load an assembly by name only:
1) The current processes main directory (where the executable file is located that started the current process)
2) The Global Assembly Cache
and in that order!
LabVIEW adds to this the ability to remember where the assembly was last referenced from if it is directly referenced from a VI and to request loading of that assembly by absolute path.
In the IDE it also populates the .Net App Domain with the directory in which the current project file is located, so that the .Net CLR also will search in there for assemblies requested by name.
When you build an application LabVIEW does one of two things:
1) If the assembly is referenced from the GAC it only stores the assembly name itself without any path and assumes that the assembly will be present in the GAC on every computer on which it is installed.
2) If the assembly is referenced from somewhere else, LabVIEW will create a copy in the support folder for the build app, which is usually called Data and store a relative reference to this location in all the VIs referencing this assembly. And it will load that assembly by building the full path from this relative path and requesting the .Net CLR to load this specific assembly. In this second case you can update your SomeAssembly.dll on the computer as many times as you like, the SomeAssembly.dll in the applications support directory will be loaded anyways, except if your system has some global manifest somewhere that blocks this specific version of SomeAssembly.dll to be loaded in which case the .Net CLR will attempt to find some other version somewhere.
Clear? No probably not, but that is how .Net generally works. 😀
In that case a new version would only be picked up if you replace this DLL instance on disk. .Net specifically favors local copies of assemblies above global copies (unless there exist specific manifests on a machine that tell it to do otherwise) since the presumption is that if there is a local copy present, it must have some good reason (otherwise it could have been installed in the GAC).
It assumes (maybe wrongly in many cases) that whoever developed the application and decided to use local copies of assemblies, very much knows what they are doing and that it is therefore a bad idea to second guess that.
You should be able to go into the VI where you placed the Constructor and reselect the new assembly file from disk. Then LabVIEW will update to reference this assembly. Since CLR 4.0 the version number (and public key) is considered part of the assembly name specification. Unless there is a manifest present for an assembly that tells .Net to prefer a different version over the one requested it will only load the requested version.
You should be able to go into the VI where you placed the Constructor and reselect the new assembly file from disk. Then LabVIEW will update to reference this assembly. Since CLR 4.0 the version number (and public key) is considered part of the assembly name specification. Unless there is a manifest present for an assembly that tells .Net to prefer a different version over the one requested it will only load the requested version, especially if the major revision changed!
In .Net (and other software too) a change in major revision is usually used to indicate binary incompatible versions of assemblies. And .Net will not automatically load a significantly higher version number than requested.
