LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I use 1 VI that will used .net dlls in different folders

I am trying to use 1 VI that will call .net dlls located in different folders. I have been able to create a VI that will call .net dlls located in the same folder by putting the VI in that same folder. When I have the .net dlls located in different folders then I have a problem. The limitation as far as I know is that the VI needs to reside in the same folder as the .net dlls so if the .net dlls are in several folders then there's a problem. Are there any way of doing that?
 
Thanks,
 
Hammadoun
0 Kudos
Message 1 of 5
(2,324 Views)
Which version of LabVIEW are you using, as the way .NET assemblies are handled is different between 7 and 8. In 7 private .NET assemblies had to be in the same folder as the top-level VI. In 8.x private .NET assembliy locations are saved with the VI, but as a relative path.
0 Kudos
Message 2 of 5
(2,315 Views)

I am using LabView 7.1. Are you saying there's a way of doing that in LabView 7.1? If that's the case, how is that done? that'd great.

Thanks,

Hammadoun

0 Kudos
Message 3 of 5
(2,311 Views)
I think that you can this by registering the DLL in the GAC, but I don't know the specifics. I think MS has a tool for doing this.

___________________
Try to take over the world!
0 Kudos
Message 4 of 5
(2,304 Views)
In LabVIEW 7.1 a private assembly needs to be in the same folder as your top level VI. I'm not 100% sure, but if you have a subVI that is referencing the .NET assembly and you have this subVI in a subdirectory then you will also need to register the assembly using the registration tool in the "Tools->Advanced" menu. When I had my project in LabVIEW 7.1 I had to have my .NET assemblies in three different places! That was because I had three different top-level VIs, and the .NET assemblies needed to be in the same directory as the top-level VI. At least with LabVIEW 8 the assemblies are referenced by a relative path, so that I could keep them in one place.

As mentioned in the previous post, you can place the assemblies into the GAC. However, in order to install a .NET assembly into the GAC it needs to be strongly named so that it has globally unique identifiers. Private assemblies are meant to be used by a single application and are distributed with the application, and reside in the application's directory (or specific subdirectories). A shared assembly is meant to be used by multiple applications, and this is allowed to be installed into the GAC. If you need to convert your private assembly so it's stronly named, you can check MSDN, or take a look here for a brief overview.
0 Kudos
Message 5 of 5
(2,298 Views)