LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Built exe not referencing correct .NET assembly locations

Solved!
Go to solution

Hello-

 

I'm writing LabVIEW code to call a private .net assembly. This eventually needs to be a built executable.  The assemblies are .NET 4.0, I've added the config file to make this possible (both on my development machine and the production machine).

 

On my development computer, everything works just fine.  I see in the project dependancies my dlls are being referenced from where I want them to be, C:\Project\Bin.

 

When I create the build specification and select preview, and LabVIEW is trying to copy my dlls into the data subdirectory.  This is the root of the problem.  The production machine already has the identical dlls, in the folder we want (c:\project\bin).  There are a lot of interworking assemblies, I'm only calling a few of them.  So it's more important for these dlls to stay where they need to be (i.e. it's a requirement, the dlls must remain in c:\project\bin)

 

If I let LabVIEW copy those dlls where it wants, they don't work because the assemblies cannot find the rest of the dlls.  i.e. The dlls in data don't know where the bin folder is, those dlls all have relative paths. 

 

Here's what I've tried:

 

1) I tried setting the data folder to be the bin where the dlls are.  LabVIEW will not build the exe.  "File already exists"

 

2)  I tried deleting the dlls from data, forcing a LabVIEW pop-up to search for the dlls.  This is weird....when I select the correct dll from the bin folder, LabVIEW says "File Not Found"  I really don't understand the problem here since I'm telling LabVIEW exactly where the dll is, and the dll is an identical copy of what it's looking for.  While not the ideal long term solution, it would allow me to continue the prototype and greatly help my schedule.

 

3)  I tried creating the exe at the root level, since I read that LabVIEW would look for assemblies in subdirectories.  I then removed the dlls in data on the production machine hoping LabVIEW would find the others.  File not found.  Pop-up to search, select correct dll, file not found again (same as above)

 

4)  I tried including the path in the Project Options >> VI search path.  No luck (didn't think this would work for the exe, but easy to try)

 

5) I tried a variation of the first option ...the idea was to move all of the dlls to anther directory, recreated my test vi, then in the build, set the data dir. to be the bin location I'll have on the production machine.  Essentially tricking LabVIEW.  But I had to update the constructor nodes, which then errored, I'm guessing because all of the assembly paths were messed up since I moved them.  I'm not sure, but I don't think this is an option.

 

So...this seems SO simple.  I want LabVIEW EXE to call a dll, why can I not just tell LabVIEW where the dll is?  Am I missing something stupid or simple?  What is with all of this convoluted copying my dlls somewhere I don't want them?

 

Any help or ideas are greatly appreciated!

 

-Harvster

 

 

0 Kudos
Message 1 of 9
(5,764 Views)
Solution
Accepted by topic author Harvster

I've gotten a kindof shoddy work around to at least allow the program to run.  Still VERY unhappy with the way this works.

 

So, I build my application in a flat structure (placing the "data" folder items in the same folder as the exe), then copy all of these files to the production box and place them into c:\project\bin.  This allows the LabVIEW exe to find the dlls and the dlls to find other dlls they may be referencing.

 

Crappy procedural caveats:

 

--Somthing not obvious is that I have to replace the dlls I already have with the ones that LabVIEW included even though they're identical. Nothing has changed about those dlls. Apparently LabVIEW is doing something to them.  Even though they still seem to be identical.  I'll have to do a binary diff to determine what LabVIEW is changing (A better question is WHY LabVIEW app builder messing with my dlls?!?). 

 

--The project cannot be rebuild.  LabVIEW app builder includes my dlls, so when I try to rebuild, they are already there and the build fails.  I have to manually delete the dlls each time I want to rebuild.

 

Right now there is a problem with dlls and referencing, but at least the app will run now. 

 

Thanks to anyone that took the time to read the problem.

0 Kudos
Message 2 of 9
(5,726 Views)

I've extensively used DLLs in my LabVIEW code via .NET. I've never had issues although I do remember this. I've tried to specify the path of the DLL when I build the EXE & Installer. LabVIEW by default may copy your dlls to the data folder but you should be able to modify this.

 

Also, if I am building the installer, I use the command line there to install the DLL after the LabVIEW executable is installed.


Kudos are the best way to say thanks 🙂
0 Kudos
Message 3 of 9
(5,717 Views)

Hello,

 

After reading this forum i founnd out some information that can be useful in the case on using .net assemblies on LabVIEW. One of the important subjects i the version of the .net framework in which the .net assembly was created and the currently .net framework on our PCs. LabVIEW supports up to .net 3.5 however there ways to run .net assemblys of other version using LabVIEW


Versions 2.0 3.0 and 3.5

 

http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/configuring_clr_version/

 

Version 4.0 

 

http://digital.ni.com/public.nsf/allkb/32B0BA28A72AA87D8625782600737DE9?OpenDocument

 

You to create 2 config files: 1 for LabVIEW and another for the application in case you build and exe file.

 

Regards,

 

Randy

Randy @Rscd27@
0 Kudos
Message 4 of 9
(5,507 Views)

Hi all,

 

 

You all seem pretty knowledgeable about .NET assemblies, so I thought I would post an issue I have been having.

 

I have been trying to use VIPM to distribute drivers that rely on a .NET framework that is unsigned (i.e not in the global assembly cache).  My issue is that after the package is installed, none of the VIs will work because LabVIEW cannot locate the .net assembly.  However, if I launch labview by opening the library VIPM installed, all of the VIs will work, and LabVIEW is able to locate the the .Net framework and it appears in the main application instance.  I need to be able to use the installed vis all the time, not just when LabVIEW is launched in this particular way.  If anyone knows how this could be done it would be greatly appreciated.

 

Here is a link the all the files I used: 

 

https://www.dropbox.com/sh/yjt2a0t8msxhgfn/AAC4VVW-hPawwXtGMrZ6wuIra?dl=0

 

Here are the steps I went through:

 

1) We put all the .NET dlls and the LabVIEW.exe.config file in the Labview directory.

 image 1.png

 

2) We installed the package on our computer.  

 

 image 2.png

3)We closed everything and relaunched Labview from the start menu.  Then accessed the BioRobotics/Vicon palette.

 

 image 3.png

 

 

4)We placed the Get Ref subVI on the block diagram, opened it up, and ran it it.

 

5) We got the following error:

image 4.png

 

We also get a similar error for any VI that uses a method associated with the .NET dll.

 

6) However, if we again start with everything closed and launch Labview by clicking on the VICON.lvlib located in the vi.lib

 

 image 5.png

 

7) Then repeat steps 3 and 4.  We do not get any errors in the VIs on the palette, and the .Net assembly loads fine.  We can even close the library and everything still works.  Somehow opening the library first makes LabVIEW know to load the ViconDataStreamSDK_DotNet assembly when using functions on the Vicon palette.

 

 image 6.png

If anyone does attempt to build a new package, it is worth noting that I included the dlls in the source files, and in the same folder as the vipb:

 

 image 7.PNG

 

Thanks!

 

Callan

 

0 Kudos
Message 5 of 9
(5,403 Views)

Hello Cal27,

 

Thank you for posting to the discussion forums. I will be happy to assist you with this issue, however I think this issue will get more visibility from members of the forum if you create a new forum post. Since this is a reply on an older forum post, it will not be shown as prominently as a newer forum post.

 

Best Regards,

 

Andy M.

Applications Engineer

National Instruments

0 Kudos
Message 6 of 9
(5,376 Views)

Hi Andy,

 

Just posted created a new forum post.

 

Thanks,

 

Callan

0 Kudos
Message 7 of 9
(5,365 Views)

@Cal27 wrote:

Hi all,

 

My issue is that after the package is installed, none of the VIs will work because LabVIEW cannot locate the .net assembly.  However, if I launch labview by opening the library VIPM installed, all of the VIs will work, and LabVIEW is able to locate the the .Net framework and it appears in the main application instance.  I need to be able to use the installed vis all the time, not just when LabVIEW is launched in this particular way.  If anyone knows how this could be done it would be greatly appreciated.


That's a pretty clear giveaway of the actual cause of this problem. When you launch LabVIEW normally the current directory for the process is set to the directory in which LabVIEW.exe is located. When you launch it by double clicking an assiciated file type, Windows Explorer (more precisely the Windows shell) will instantiate the process and set its current directory to the directory in which the file is located on which you clicked.

 

LabVIEW will request from Windows to load the direct DLLs with the explicit full path stored in the VI but any of these dlls depending on other dlls will only reference them by name. Now Windows when prompted to load a DLL by name only will look in certain locations for such dlls. The searched loacations are these:

 

1) if already loaded use this dll

2) if a full path is provided when requesting to load a dll, try to find it there (this is what LabVIEW requests for DLLs referenced from a VI)

3) the current directory for the process (set to the LabVIEW directory when LabVIEW is started normally but to the directory in which you clicked on a file type when it was started through a file association through the shell (Explorer)).

4) system directory

5) Windows directory

6) any directory listed in the PATH environment variable

 

This is for normal DLLs, the search order for .Net assemblies is by default much shorter and only contains 1), 2), 3) and the GAC. But the important point is step 3)! 

One or more of the DLLs that are called by LabVIEW reference other DLLs in that directory and if even one single dependency can't be satisfied Windows will simply abort loading the initial DLL and return an error to LabVIEW that the DLL (assembly) could not be loaded.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 9
(3,482 Views)

i also faced similar issue, this link might help you

http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/configuring_clr_version/

 

read the note mentioned at last of the article carefully

0 Kudos
Message 9 of 9
(2,752 Views)