Dot Net Library interfacing with Kinesis Thorlabs

[AlAs_82]

Hi all,

I have been working with the Thorlabs Kinesis Thorlabs libraries to create a stand alone vi that I can incorporate to my experiment. 

However I have been having some issues with the dotnet libraries. The problem is that when I have the Kinesis labview project open the VI runs smoothly. When I try to run it while having the kinesis examples project closed the vi doesn't work. Anyone know how I can get around this?

I have been seeing the same thing with other VIs based on dotnet libraries. Do the Dotnet dlls have to be placed in a specific folder in order for Labview to load them?

Cheers

Alexis

[rolfk · Accepted solution]

There are two general locations Windows will attempt to locate .Net libraries in, one is the General Assembly Cache or GAC and the other is the directory in which the executable file for the current process resides. LabVIEW adds to this the directory in which the project file is located.

If you run outside of a project you are left with the two standard locations that Windows will search! For execution in the LabVIEW development system this means the directory in which labview.exe is located, for execution in a build application this would be the location of <yourapp>.exe.

Adding files to the LabVIEW directory itself is VERY BAD behaviour and should be avoided by all means.

[Kyle97330]

I've done Kinesis programming in LabVIEW before and it is indeed less than optimal.  110 DLLs or so, all related to each other.

There is one thing I've found that you can do.  If you've already loaded a reference to a DLL in LabVIEW somewhere, it will use that reference instead of looking for the DLL on disk.  This can be a property node, invoke node, constructor node, or even just a block diagram class constant.  It doesn't have to do anything either, it just needs to be on a VI that gets loaded somewhere that doesn't run and doesn't break the VI.

It's not perfect, but if you don't want to use a project file, or you do want to but don't want to copy all the DLLs to where your project file is located, it's the only way I found.

[AlAs_82]

I see. Many thanks. This aswered a lot of questions I had and saved a lot of debugging time. You say that "LabVIEW adds to this the directory in which the project file is located". Is there a way to set this up also for a VI?

Otherwise as I understand  my options are either to copy the library to the GAC or in the folder where the labview executable is (which as I understand is not advisable).

I will try the GAC first and see how it goes. 

[rolfk]

.Net uses so called load contexts. It possible to add extra locations to that by calling .Net functions but you should familiarize yourself with the topic more by reading this and related documents. There are drawbacks to extending the load context including security concerns about foreign code injection.

Also if you decide to go this path you would have to implement a two stage architecture when starting up your application. The first stage will configure the load context for your application and only after that has been accomplished can you start to load any VIs that will reference assemblies in the prepared locations.

It will most likely mean to create a loader application that will prepare everything and then invoke dynamically your main application, while the loader application will have to stay in the background to make sure the .Net objects that it invoked to alter the load contexts will stay alive for the duration of your program.

[Kyle97330]

If you have a modern version of Windows (7 or later) the GAC is basically inaccessible unless you have Visual Studio and know how to use it.  It sounds easy and ideal... but it's not...