LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DLL is always copied during creation of lvlibp

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

 29-01-_2018_08-27-17.jpg

 

0 Kudos
Message 1 of 4
(2,451 Views)

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).

0 Kudos
Message 2 of 4
(2,434 Views)

The scriptengine is a .net dll.

 

29-01-_2018_10-35-43.jpg

 

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.

 

 

0 Kudos
Message 3 of 4
(2,420 Views)

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.

0 Kudos
Message 4 of 4
(2,412 Views)