Issues running a LabVIEW DLL Prj which includes .NET assemblies

[nitulandia]

Hello,

General Info:

- LV Ver in use: 8.2

- "Development PC" with Full development LabVIEW ver installed

- "Production PC" with only the LV 8.2 RTE installed

Test Details:

- I have a "Dev" machine on which I'm running a .VI successfully; The .VI is a wrapper to .NET assemblies; All works as expected.

- I have successfully compiled a LabVIEW DLL (MyTest.DLL), and runs as expected on my "Dev" machine. The first thing to note is that in the process of creating the LV DLL, LabVIEW creates a "DATA" folder at the location where the new DLL is created. Inside this "DATA" folder, I see that LabVIEW has put two .NET assemblies I use in my project. Just for you information, these two .net assemblies call several other DLLs, some by static and some dynamic reference. By the way, I know that I'm dealing with a total of at least 10 .NET assemblies, all of them which were included in my LV project.

Hopefully what I wrote above makes sense...if not, please let me know and I'll try to provide more clarification.

- Next I copy MyTest.DLL to the "Production PC" along with the DATA folder created.

- When I try to run the test on the "Production PC", an exception is generated by one of the .NET dLLs: it complains that a .NET DLL could not be found at the "DATA" folder. If I manually copy the .NET DLL to the "DATA" folder, all works as expected.

A few weeks ago I had posted something similar, however, this time around the post is a bit different. When I proceed to create my LabVIEW DLL, it appears that LV knows that I'll be using two .net assemblies, but doesn't know that those assemblies will use some other .NET assemblies being called by reference. I have put a work-around in my code, where I programatically copy some of these DLLs to the DATA folder if they are needed.

Regardless, can any of you comment on the behavior described above?

And, I'm also curious about the following: why does LabVIEW create a DATA folder in the process of outputing any given DLL ?

I look forward to your comments.

Cheers,

edp

[Mark Smith]

I think this is exactly what you should expect. LabVIEW won't have any knowledge of which .NET assemblies get called unless LabVIEW specifically links to them with an Invoke/Property/Constructor node. So the LabVIEW builder won't automatically include any of the .NET assemblies it doesn't know about. If the referenced assemblies are part of the .NET runtime (like anything in mscorlib namespace) it's in the GAC (global assembly cache) and available to all other .NET assemblies without any other effort on the developer's part. If the assemblies referenced are developer defined (not part of the .NET framework), then the developer has to specifically get them on the target machine. You could put them in the GAC (but they must be strongly signed), but the easiest way is just to include them with your app by going to the Source Files pane on the Build Specification for your DLL and add the assemblies you need to Always Included. Then, all of the assemblies you need will get copied to your Support Directory - the path is shown on the Destinations page of the Build Specification - which defaults to the Data folder unless you change it. Without a good reason to change it, you should just leave it as is since the LV exe will always look first in the Data folder for support files. So the search path is LV exe -> Data Folder -> top level .NET assembly -> Looks for other .NET assemblies in 1) Data folder (.NET always looks in the same folder as the root assembly) -> GAC -> custom destination(s) - set by the calling assembly' s manifest? I not sure I recall this correctly.

Mark

Edit: Another possible course is to create a top level assembly in the .NET environment and build it as a DLL and then call that from LabVIEW. Visual Studio will detect dependencies and allow you to build a DLL and installer that includes all of the dependencies of the .NET DLL.

[nitulandia]

Hi Mark,

Your suggestion, "the easiest way is just to include them with your app by going to the Source Files pane on the Build Specification for your DLL and add the assemblies you need to Always Included" has solved the issue :thumbup:

I can now eliminate the work around I had put in place previously.

Thank you much.

Cheers,

edp