Showing results for 
Search instead for 
Did you mean: 

Issues Calling C#.NET DLL from LabVIEW

TeaAndBiscuits -



The LabVIEW help file actually describes this situation exactly here, for each of the use cases. For the first two cases, it basically save: use a project if you are loading .NET assemblies. It precisely says:


"If you call a .NET assembly from a VI that does not belong to a project, you technically can save the assembly in the same directory as its calling VI. LabVIEW searches certain VI directories, including the calling VI directory, for assemblies that the CLR cannot load by default. However, calling assemblies stored in this location can result in name conflicts and other unexpected .NET behavior. Therefore, National Instruments does not recommend that you save assemblies in this location."


Regarding use case 3, you should be able to setup a project in an arbitrary location and load an assembly in another location, but the location of the assembly must fall under one of these two conditions:

  -  searchable by the The Common Language Runtime (CLR), which I think is the GAC folders described above

  -  "If the CLR cannot find the assembly, LabVIEW then searches for the assembly in the same manner it searches for missing VIs."


So if you specify the location in the Paths page or the Options dialog box, then LabVIEW will find it like any other VI, and it should load.

- Regards,

0 Kudos
Message 11 of 17

Just to mention, I such cases I always use "attach to process" from C++/C#  IDE. Or WinDbg as an extreme :-).

Thus it possible to keep a track on what is going on inside a dll - loading, unloading etc. 

LV 8.2 at Windows & Linux

0 Kudos
Message 12 of 17

I believe I'm having a related issue. I have an assembly in a relative path to my VIs (in a subfolder called DLLs). I then use this collection of VIs and associated DLLs in several projects (the VIs are actually part of a LVclass and the object ref in stored inside the class cluster).


The issue I seem it be having is that (a) LabVIEW seems to be storing an absolute path instead of relative (when I make a copy of the code somwhere else to use in another project I either find out that its linking to a different version somewhere else or I get a "dependancy was loaded from a different path" warning.


This leads me to my next issue - (b) every time the code is loaded up from a differnent location (such as another developer's PC, or a test station's hard drive, etc) the whole code needs to be recompiled and saved!


Is there any way around these issues? Calling GAC registered assemblies seems to be great, but individual assemblies and LabVIEW seems to be such a headache. (oh, I'm on LabVIEW 2009, evaluating whether we can upgrade to 2010 right now)

0 Kudos
Message 13 of 17

I don't know of a particularly elegant way around that. If assemblies are in different locations on different machines, the best labview can do is try to search for them (which it typically does). Normally the only time I see this happen is between OS versions and widely spread versions of LV. If you'd like to provide a small example I'd be happy to play with it and look for a solution!

0 Kudos
Message 14 of 17

I also have a .Net dll that actually implements a custom step type for TestStand and is stored in the TestStand Components\StepTypes folder.  I want to allow Labview test modules to also call this .Net module, as it is not registered in the GAC I also have this issue.  While a developer can code there Labview test fine there are deployment issues as the TestStand files may not appear in the same place on every machine (Windows profile dir sometimes on C: other times on D: for example).


This appears to be the same issue as many years ago when the call library function node.  This too had the limitation of wither providing a fixed path or relying on Labiew search to locate. Now however Labview has been improved to allow the user to provide a path to the DLL. This allows utility vi's to be coded to provide the install path of the modules at runtime. I just hope this kind of feature finds its way into the .Net functions soon.

0 Kudos
Message 15 of 17

If different tests don't show up in the same places, you should at least have a directoy location for each test for organization purposes. Then the subdirectories of that VI should be included as described in Path Information When Searching For SubVIs. When you install a new application on your computer, the app puts all of the files in that one directory. This is explained from the article Distributing .NET Assemblies:


After you create a VI that includes .NET components, you can build that VI into a shared library or stand-alone application. LabVIEW copies the associated private .NET assembly files to the data subdirectory in the same directory as the library or application.

You also can distribute .NET VIs to another location. If you distribute .NET VIs, libraries, or stand-alone applications, you either must move the associated private .NET assembly files to a subdirectory that LabVIEW can search, or you must save the files in the GAC or in another location that the Common Language Runtime (CLR) searches.


LabVIEW will demand that the file is associated (aka in the directory of) to some known standard spot, either associated with the calling VI by being located in a subdirectory path of that VI, in the standard GAC location, or in an established location for your third party assemblies which you then manually add to the VI search path as described in Adding a Directory to VI Search Path.

- Regards,

0 Kudos
Message 16 of 17

I noticed the .NET assembly path becomes relative after installing f2 patch for 2011SP1. Before installing the patch, the path was absolute.

0 Kudos
Message 17 of 17