Handling .NET .dll-files, that are called from several packed libraries

[wlukas]

Hello community,

I am currently working on a project containing several packed libraries. Right now we are in a state of rearranging project files and dependencies and now want to create the right structure to prevent dependency problems in the future.

My problem is, that when packing libraries, that in themself are calling .net assemblies, I can not prevent LabVIEW from copying those .net assemblies and thereby changing the dependency to the build output path.
When I now pack a second library, that uses the same .net assembly, and include it into a project I get dependency warnings, because the .net DLLs are being called from different locations.

Ticking the box "exclude depending DLLs" in the build specifications does not do anything for me, which I don't understand.

Did anybody had similar issues or another solution of arranging packed libraries, that use DLLs?

Best regards
Lukas Wiese

[MelanieE]

Hi Lukas,

can you please explain what you mean by "Ticking the box "exclude depending DLLs" in the build specifications does not do anything for me, which I don't understand." What did you try and what was the outcome?

Additionally, can you tell a little bit more about the DLLs you call? Why do ou have to integrate them into multiple lvlibp's? Having kind of a wrapper lvlibp would be a more sufficient solution in my opinion because it avoids issues if one of your lvlibp's may update the DLL to a different version.

Best,

Melanie

[wlukas]

Thanks for your reply!

The .NET DLLs are just called by one packed library each. But because my packed libraries have dependencies between each other, the .net dll gets copied to the build path when compiling a top level packed library. As every Packed library needs to have a separate build path (otherwise LabVIEW complains about that you can not pack a library to where a depending library is located), The DLLs now got copied to several separate folders during library packing and i thereby get load errors, because different libraries want to load the same file from different locations.

My temporary fix for this problem was having a separate build and "dependency" folder. I pack all libraries into the build folder and a post-build script then copies the packed library to the "dependency" folder. This dependency folder now contains all my packed libraries and the .NET dlls. Different projects that use those libraries all call them from this folder. I implemented this after first asking my question here.

This worked incredibly well when staying inside the development environment and resolved all my load- and dependency errors as all dependency files where located in one place, the dependency folder. 
Unfortunately this approach does not seem to work when building a project into an .exe-file. During building I don't get Errors, but when opening the executable my packedlibs are not found and i get error 6208 or 6308 depending on which libraries I include. This happens even though all packed libraries get copied to the build location of the executable just fine. 

How can it be, that the built executable is not able to open the files that are directly located inside it's folder?

Lukas

[aptivo · Accepted solution]

There are a few ways to deal with that issue. To ensure, that each ppl has its own dll, you have to rename those with individual names for each ppl. If you’d like to share the dll files, you have to implement a common structure, like all ppl stored in the same folder and sharing the same relative path to the dll- file. The same has to apply to the executable. For the executable add the shared common structure to the project and pay attention to the relative path from the ppls with respect to the shared code. This works fine for me.

[wlukas]

Thank you so much for your reply!
I Indeed had different relative paths for the executable and for the development program and changing this did resolve my error 6308.