dlanger Posted May 8, 2012 Report Share Posted May 8, 2012 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? Link to comment Share on other sites More sharing options...
Ashish Posted May 10, 2012 Report Share Posted May 10, 2012 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. Link to comment Share on other sites More sharing options...
dlanger Posted May 15, 2012 Author Report Share Posted May 15, 2012 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... Link to comment Share on other sites More sharing options...
Michael Aivaliotis Posted May 21, 2012 Report Share Posted May 21, 2012 Can you post your DLL and a VI that calls it so we can reproduce your problem and hopefully resolve it? Link to comment Share on other sites More sharing options...
dlanger Posted May 22, 2012 Author Report Share Posted May 22, 2012 The project can be downloaded from: https://github.com/dominiklanger/LabbitMQ Just click on the ZIP button... Link to comment Share on other sites More sharing options...
Ashish Posted May 24, 2012 Report Share Posted May 24, 2012 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. Link to comment Share on other sites More sharing options...
dlanger Posted May 29, 2012 Author Report Share Posted May 29, 2012 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? Link to comment Share on other sites More sharing options...
dlanger Posted June 11, 2012 Author Report Share Posted June 11, 2012 Hi Ashis Did you use LV2011 when you could solve the problem by mass-compiling? I posted the issue also on the NI forum: http://forums.ni.com/t5/LabVIEW/labview-2011-forgets-new-dependency-path/m-p/2014724#M661379 Link to comment Share on other sites More sharing options...
Harlequinade Posted June 15, 2012 Report Share Posted June 15, 2012 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. Link to comment Share on other sites More sharing options...
Harlequinade Posted June 15, 2012 Report Share Posted June 15, 2012 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.