Jump to content
dlanger

Wrong path for DLL with .NET assembly

Recommended Posts

I created a package with VIs that make use of .NET classes. After installation, when I drag a VI from the newly created palette onto the block diagram, LabVIEW searches for a couple of seconds for the DLL, eventually finds it in the folder into which my VIs have been installed by the VIPM and then displays a dialog message that a dependency has been loaded from a new path:

 

The .NET assembly expected to be at "C:\.LabbitMQ\RabbitMQ.Client.dll" was loaded from "C:\Program Files\National Instruments\LabVIEW 2011\vi.lib\Zen Informatics\LabbitMQ\RabbitMQ.Client.dll".

 

Is there any way to get rid of the searching and the displayed message?

Share this post


Link to post
Share on other sites

dlanger,

 

One recommendation I can have to to include the DLL name instead of the DLL file path in the "Call Library Node" as shown in this link: http://screencast.com/t/U7eATG2pNSn

 

Also, the DLL should be located inside the folder containing VIs to be included in the package. The package builder and VIPM will ensure that the DLL gets installed at appropriate location for use.

 

Let me know how it goes.

 

Thank you.

Share this post


Link to post
Share on other sites

Dear Ashish,

 

Thank you for your reply. Since I am using .NET classes in the DLL, I don't use the Call Library VI, but rather the .NET constructor VI in combination with .NET property and invoke nodes (see attached image). I am not aware of

 

My VIPM package consists of four LVOOP classes, each of which with an own directory. The DLL was in the parent directory. I now put all classes and their method VIs into the parent directory such that they reside in the same directory as the DLL. This didn't help, unfortunately. Somehow, the method VIs of my four LVOOP classes try to find the DLL at the original, absolute path (the one before the installation of the VIPM package). Therefore, the fact that VIPM puts the DLL at the "right" place doesn't help.

 

I am a bit lost... I just found out this morning that this DLL path issue leads to a whole bunch of further problems in a project using the package installed with VIPM. In particular, because this dependent project creates an EXE, it copies the DLL into the EXE build path. Then, when reloading the LV project, LV detects and uses (after some searching) the DLL in the build path instead of the one installed by the VIPM. This, in turn, prevents me from rebuilding the EXE because LV cannot override the already loaded DLL... So, if I cannot solve this whole issue somehow, I will have to stop using VIPM, which would be rather sad, given how nice the tool is...

post-5719-0-65639700-1337074572_thumb.png

Share this post


Link to post
Share on other sites

dlanger,

 

Did you perform "Mass Compile" on your code before building the package?

 

I was able to recreate your situation. However, mass compiling the folder before building the package appears to solve the problem on my machine.

Share this post


Link to post
Share on other sites

Mass compiling before building the package unfortunately didn't help; the problem still persists. Also, manually mass-compiling the folder containing the installed package (inside the vi.lib folder) has no impact.

 

I think, the basic question is why LabVIEW doesn't save the new path of the DLL once it has found it. Why does it always has to search it from scratch?

Edited by dlanger

Share this post


Link to post
Share on other sites

I have tried it today and noticed also this behaviour. I did as described above by Ashish to first Mass Compile the project and than compile it to the package.

Once deploying and then opening the VI again, I get this error message.

 

Notice as well the extra dot in the expected dependency path.

 

post-2979-0-59388300-1339761189_thumb.png

Share this post


Link to post
Share on other sites

I found a solution to this problem.

 

I replaced in all the private data the .Net reference with a numeric control and did type casting at the moment needed for calling the .Net methods. This solved the issue.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.