Problems calling a .dll with the .net constructor node from a vi within an llb

[psmorris]

Hi all, I'm having a problem and hope someone here can help! 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" (its 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 property node labelled "Network". I had a look at the .net constructor node at the beginning of that VI 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, I still have the same problem. I did manage to get the assembly to appear to load 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. As I say, it works fine from within a project environment, but not when loaded directly out of the .llb Any suggestions? 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! Paul (CLAD)

[psmorris]

Not sure if my attachment showed up. Heres another go:

[DanHarryman]

Hi Paul

I've been looking into your post and if I'm correct your issue is when using a LLB to call a DLL? As I understand your problem you have a program that runs fine as a LabVIEW project however when you export this as a LLB or EXE there are problems when calling a DLL that resides inside the LLB. Is this correct?

As far as I am aware this should work fine so long as the DLL is in the same directory as the LLB. But as you have stated this is the case. A way to work around this issue may be to use LabVIEW native drivers for the 3rd party piece of software. Can I ask what 3rd party device it is your working with? You can check the IDNet and see if a LabVIEW driver is already available.

http://www.ni.com/downloads/instrument-drivers/

There are also lots of resources there to help with using instrument drivers there. If there isn't a driver there then please let me know and I can look into solving this issue with you further.

Many thanks

Daniel Harryman

Applications Engineer

National Instruments

[psmorris]

Thanks for the reply.

The device in question is the Aerotech Ensemble motion controller. There doesn't appear to be a native labview driver, although Aerotech do provide some reasonable example code using their dlls.

Your assesment is basically right, when in a labview project environment, all works fine. But if I export my top level vi (along with all dependencies) to an .llb it seems to fail to properly load the .dll in the constructor node (although I should point out, the error is not being generated by the constructor, but by the property node immediately following it!).

I'd be much happier with a VISA style solution sending commands to the controller, but that's not available.

Any further suggestions would be gratefully recieved!

Paul

[rolfk]

.Net has special request in order to be able to locate assemblies. Basically you need to place the assembly into the GAC or in the same directory as the calling processes executable is located. LabVIEW adds for this an extra location which is the same directory as the project file is located, but for a build application the project doesn't exist anymore. There is not much you can do to mitigate these issues, except installing the assembly into the GAC but that requires a so called strongly named assembly which means it needs to be fully versioned.

[rolfk]

.Net has special request in order to be able to locate assemblies. Basically you need to place the assembly into the GAC or in the same directory as the calling processes executable is located. LabVIEW adds for this an extra location which is the same directory as the project file is located, but for a build application the project doesn't exist anymore. There is not much you can do to mitigate these issues, except installing the assembly into the GAC but that requires a so called strongly named assembly which means it needs to be fully versioned.

[psmorris]

Hi Rolf,

Thanks for the reply - can you "dumb it down" a little for me ;o) whats the "GAC"?

you say: "Basically you need to place the assembly into the GAC or in the same directory as the calling processes executable is located

Assuming I'm running in a labview dev environment, does that mean I can drop the assembly into the labview directory? 

If I'm running from a built exe, can I then drop the dll into that applications directory?

Thanks again for your help.

Paul

[rolfk]

---

@psmorris wrote:

Hi Rolf,

Thanks for the reply - can you "dumb it down" a little for me ;o) whats the "GAC"?

you say: "Basically you need to place the assembly into the GAC or in the same directory as the calling processes executable is located

Assuming I'm running in a labview dev environment, does that mean I can drop the assembly into the labview directory? 

If I'm running from a built exe, can I then drop the dll into that applications directory?

Thanks again for your help.

Paul

---

1) GAC: Global Assembly Cache, the global location in Windows systems where all installed assemblies should be stored.

2) Yes in the LabVIEW development system it would be the directory where labview.exe is located, but that is a bad idea to do. Since LabVIEW treats the directory where the project is located in similar ways, you should rather use that directory. For build applications however you should indeed place the assemblies in the same directory as the executable, if you can't have the assemblies installed in the GAC.

[psmorris]

Sorry to be a pain - what's the method for installing into the GAC?

Thanks.

Paul

[psmorris]

Just found  %windir%\assembly\ to view and drag drop. It didn't argue when I dropped the dlls into there. so that must be a good thing!

Having done that, do I need to change my code to reflect where they are? Or will labview just automatically look for them there if it can't find them elsewhere?

Finally, assuming the above works on my development machine, is there a neat way to install the dlls into a users GAC without needing to drag and drop as I've been able to do here?

Thanks for all your help - I think I'm getting there!

Paul