.net constructor problem within .llb plugin

[PA-Paul]

Hi All, 

 

Posted this yesterday on ni.com (http://forums.ni.com/t5/LabVIEW/Problems-calling-a-dll-with-the-net-constructor-node-from-a-vi/td-p/2282712) as I couldn't get in here for some reason. Not had a response yet so thought I'd throw it here... I also note my formatting got messed up on ni.com...

 

For info, I'm using Labview 2012f3 and windows 7.

 

I have a hardware control application which we wrote to be nominally device independent. We did that by writing our own device drivers (in labview) which are distributed as .llb files, with the top level vi within the llb being the main "driver" (the top level vi is basically an action engine that can be called then by the main application.). This model has worked well for us with drivers which are written natively in labview, typically using VISA to communicate with the various bits of hardware.

 

We now need to add support for some 3rd party hardware which has a driver written with .net calls to dlls and the like. I have successfully written the driver in as much as it works fine when used standalone from within its own labview project. However, when I build my distributable llb version of the driver, it gives an error when run (note that the top level VI is executable, its not reporting as broken).

 

The error is a generic "error 4" at the first property node that accesses something from the dll. In the attached file, the error occurs after the first property node labelled "Network" (reading the "Controllers" property).

Although the constructor node itself is not generating an error when run, I had a closer look at it and when I click "Select constructor", the correct assembly is listed in the assembly drop down. But within the "Objects" list, all I have is the message: "an error occurred trying to load this assembly". I tried browsing for the assembly, but that doesn't change anything. The .dll is placed in a "data" folder which is in the same folder as the llb file. But even if I put the dll in the same directory as the llb, I still have the same problem.

 

I did manage to get the assembly to appear to load quasi-correctly in the "select .net constructor" dialogue by first browsing to a related .dll (a "common" dll provided by the 3rd party"), but when I then selected the "network" object from the list, all refnum wires to the right of the property node in my attachment break and the VI becomes broken and cant run at all.

 

As I say, it works fine from within a project environment, but not when loaded directly out of the .llb Any suggestions (either when called by the main app, or even when loaded into labview from the llb)?

 

Ultimately I need this to be able to work with a built executable calling the top level file in the llb, (otherwise there'll be a huge amount of work involved in changing the way the drivers are loaded I suspect).

 

Thanks in advance!

[ShaunR]

Do you still have the same issue if you put the assembly in the system32 folder?

[Rolf Kalbermatter]

Do you still have the same issue if you put the assembly in the system32 folder?

 

.Net assemblies should not be placed in the system32 folder. The .Net loader will not pick them up from there. Instead they need to be placed in the GAC (Global Assembly Cache) or in the directory where the executable of the calling process is located. In the case of LabVIEW development environment, the better place is the actual project directory as LabVIEW registers that as well with .Net when loading a .Net assembly from within a project context. But if possible .Net assemblies should be installed into the GAC by an installer.

[ShaunR]

.Net assemblies should not be placed in the system32 folder. The .Net loader will not pick them up from there. Instead they need to be placed in the GAC (Global Assembly Cache) or in the directory where the executable of the calling process is located. In the case of LabVIEW development environment, the better place is the actual project directory as LabVIEW registers that as well with .Net when loading a .Net assembly from within a project context.

Thanks for the detailed explanation. I avoid.NET a (and ActiveX) like the plague, so I was taking pot shot at a path issue.

 

But if possible .Net assemblies should be installed into the GAC by an installer.

Added to my list of "reasons (excuses) not to use .NET"

[Rolf Kalbermatter]

Thanks for the detailed explanation. I avoid.NET a (and ActiveX) like the plague, so I was taking pot shot at a path issue.

 

Added to my list of "reasons (excuses) not to use .NET"

 

I haven't really used .Net so far, other than converting some .Net code to Java! And creating a .Net binary module for LuaVIEW for a client in order that they could interface to .Net drivers from within our test application.

 

But specially that last one forced me to learn more about .Net than I ever cared to know. Anyhow I rather write a standard C shared library from scratch than integrating .Net into LabVIEW applications myself.