01-29-2018 01:30 AM
Hi everyone,
in our "scriptengine" project which is going to be used in other Projects some VIs use a DLL.
To be easily used in other projects, I create a lvlibp.
Now during build of the lvlibp the DLL is always copied from source to destination directory. Then I have two DLLs and LabVIEW gets confused from which directory to load the DLL.
I have checked "exclude dependent libraries" in build specifications.
It does not make a difference if I include the DLL in the scriptengine project or delete it from the project and see it in dependencies.
Some self-made DLLs I can register in the GAC, but for sapnco.dll e.g. I can not do that.
Do I have to make a VI which deletes the copied DLL after the build or what can I do?
Thx in advance
01-29-2018 02:12 AM
What kind of dll's are that? ActiveX, .NET or normal PE dll's (call library nodes)?
If they are call library nodes, you can try to specify it's path on the diagram. That way, LabVIEW won't have a concrete path at compile time to copy. Of course, the code will get a bit more complicated...
With .NET dll's I think by default the dll is not copied. I had to drag the dll into a class (used in the code) to make LabVIEW copy it (to the executable, but that should be more or less the same as a lvlibp).
01-29-2018 03:51 AM
The scriptengine is a .net dll.
I can simply not find a way for LabVIEW to not copy this DLL.
If I move it to the class, it changes to "always included". As it is now, it is on "included if referenced".
If I build an application .exe from any VI inside the class, the DLL is also copied.
01-29-2018 07:32 AM
Ok, so that explains a few things about my situation...
My class is dynamically loaded by a parent. This is because, depending on certain conditions, it's not always included... So when it is included, I have to put the dll in the class, so the .dll is included.
That doesn't really get you any further, your problem is the exact opposite...
Your initial idea to make a post build VI might be the only way... Unless you want to load and call the .NET dll dynamically with .NET reflector, but that might set you back a few weeks.