What setting to set to stop .NET dll being copied to build folder

[wiebe@CARYA]

Could it make a difference if the assembly is outside the folder hierarchy of the project?

If system assemblies are not included in a ppl, I wander if it's because they are in the system (GAC) or because they are outside the project's directory hierarchy? Maybe even because they're not in the library's directory hierarchy (if the lib is not in the project folder)?

I guess moving the assembly to the GAC would help, but it isn't a very appealing option.

[rolfk]

It's almost certainly because they are in the GAC. .Net only really knows two well known locations for assemblies and that is the GAC and the application directory of the current process. Anything else is customized behaviour that may or may not work with specific assemblies.

A process can add extra directories to the AppDomain but that is custom behaviour. LabVIEW does that in the development environment for the project directory. But in an executable there is no project anymore.

If you really want to know the finer details of .Net assembly loading you can read this KB article. Expect to learn a lot more about .Net before you can even somewhat comprehend what it says there. 

[jamesbond0007]

Yes the problem that you described below is exactly the problem I have!

I am actually using the SSH.NET library and am struggling with this .

Yes I have tried to move it to a common folder (e.g. C:\Common\DLL) and have the code reference to that folder but getting the same result.

Renaming the .NET dll won't work because it will still copy that renamed .NET dll into the build folder.

[cbutcher · Accepted solution]

I was able to produce what I believe is the desired behaviour with the following steps:

1. Create a new "HelloWorld.dll" using Wiebe's snippet. This is stored in <Downloads>/HelloWorld.dll (but could be anywhere - it is not under the project)
2. Create a new project, add a library and then a VI in the library that uses a constructor node to link statically to the HelloWorld.dll in Downloads
3. Get the output of "SayHello()" and display it in an indicator
4. Drag HelloWorld.dll from Dependencies into the project (not into the library)
5. Create a build specification for PPL
6. Set destination directory as desired (not near project, in my case to Desktop\builds\NetTest\My Packed Library
7. Under "Destinations" tab, add a "Common" destination with path "C:\CommonDLLs"
8. Under "Source File Settings" set HelloWorld.dll with destination "Common" (the newly created location) and tick the rename box to Installed_HelloWorld (I don't think the rename is necessary, but I did it to check where things were moving)
9. Try the preview - I see my PPL in the destination directory, and my Installed_HelloWorld.dll in the C:\CommonDLLs directory. HelloWorld.dll doesn't appear anywhere.
10. Build the PPL
11. Close LabVIEW (all the way, not just the project). This may or may not be necessary... testing when uploading the project seems to show this isn't necessary
12. Open the built PPL (there is no dll next to it). It loads just fine, and run its VI to get "Hello World" appear in the string indicator. No error appears
13. Rename the "C:\CommonDLLs\Installed_HelloWorld.dll" to something else (e.g. _Installed_HelloWorld.dll). Observe that running the PPL's VI again produces error 1589 (error loading assembly from path C:\CommonDLLs\Installed_HelloWorld.dll)

The project, such as it is, will be attached as soon as I edit this post from my laptop 😉 Done

I'll check rebuilding by moving some stuff around to put it closer together for zipping but not in the same directories. Also done - worked fine.

[jamesbond0007]

Thanks for trying this out 😀

I tried those steps outlined by you and the .NET dll file does get copied to a specified directory instead of the same directory where the PPL resides.

However opening the PPL after it is built and at the same time, if I leave the Project Explorer opened, the conflict message still does appear.

I guess Step 11 below still needs to be done (no need to close LabVIEW). At least by closing Project Explorer, the existing .NET library will be cleared from the memory, thus removing the conflict when the PPL library is launched which will cause a new copy of the .NET dll being loaded.

I see that you have a post build vi that delete the original *.dll.

I cannot do a post-build where the original .NET dll file is being deleted because, doing that will break the developer project.

[cbutcher]

I tried out a post build VI but discovered that it wasn't needed (and didn't do what I wanted anyway).

I meant to delete it from the build spec but perhaps I forgot when I uploaded. In any case, as you pointed out, you don't want to use it 🙂

[wiebe@CARYA]

---

@cbutcher wrote:

I tried out a post build VI but discovered that it wasn't needed (and didn't do what I wanted anyway).

I meant to delete it from the build spec but perhaps I forgot when I uploaded. In any case, as you pointed out, you don't want to use it 🙂

---

Thanks for all the hard work!

Although it seems to solve the problem, the solution does have a side effect (a copy of the dll for each packed library). This 'side effect' might be acceptable for OP, it's hardly ideal.

Is it fair to say that this still is a problem in LabVIEW?

Should this be an idea on the idea exchange?

[jamesbond0007]

---

wiebe@CARYA wrote:

---

@cbutcher wrote:

I tried out a post build VI but discovered that it wasn't needed (and didn't do what I wanted anyway).

I meant to delete it from the build spec but perhaps I forgot when I uploaded. In any case, as you pointed out, you don't want to use it 🙂

---

Thanks for all the hard work!

Although it seems to solve the problem, the solution does have a side effect (a copy of the dll for each packed library). This 'side effect' might be acceptable for OP, it's hardly ideal.

Is it fair to say that this still is a problem in LabVIEW?

Should this be an idea on the idea exchange?

---

I was thinking of registering the .NET dll into GAC but this route is seems more problematic.

My original intention was to actually have both the compiled (codes in *.lvlibp) and non-compiled codes (in *.lvproj) referring to same copy of .NET dll file but it seems that this is not doable at all at build setting.

I also tried doing something mentioned here but it does not seem to work.

[wiebe@CARYA]

---

@jamesbond0007 wrote:

I also tried doing something mentioned here but it does not seem to work.

---

That does seem useful for the problem. If we can get it to work.

Did you get stuck, or did it just not work?

[cbutcher]

---

wiebe@CARYA wrote:

---

@cbutcher wrote:

I tried out a post build VI but discovered that it wasn't needed (and didn't do what I wanted anyway).

I meant to delete it from the build spec but perhaps I forgot when I uploaded. In any case, as you pointed out, you don't want to use it 🙂

---

Thanks for all the hard work!

Although it seems to solve the problem, the solution does have a side effect (a copy of the dll for each packed library). This 'side effect' might be acceptable for OP, it's hardly ideal.

Is it fair to say that this still is a problem in LabVIEW?

Should this be an idea on the idea exchange?

---

Ah. Found the quote button again 🙂

Anyway...

as to that side effect, I'd imagined that the OP would install the DLLs into some shared folder (e.g. C:\MyAwesomeDLLs\") and that each PPL would just overwrite the previously installed version with the newly installed version.

Wouldn't that work/be what was needed?

Potentially it would make a mess of versioning... but that could probably be worked around using versioned directories and symbolic links/junction points, if needed (as is common for some libraries on Linux systems).