Jump to content

dlanger

Members
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. 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
  2. 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?
  3. The project can be downloaded from: https://github.com/dominiklanger/LabbitMQ Just click on the ZIP button...
  4. 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...
  5. 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?
  6. I used the VIPM (Commmunity edition) to create a package containing a couple of LVOOP classes. In the palette entries created upon installation, only VIs are available. Is there any way to make the actual class available via the palette (i.e. on the front panel palette as a control/indicator) and on the block diagram palette as a constant? If not, would it be possible to integrate this feature in a future version of VIPM?
×
×
  • Create New...

Important Information

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