LabVIEW user.lib libraries and .NET

[JW-JnJ]

I'm looking for advice from people who have dealt with the following:

1. I'm using a third party suite of .NET dlls. In order to interface with LabVIEW, I wrote a C# dll to make a wrapper and provide easier access via properties and methods.
   • I'm very new at C#, so please bear with me
2. For our developers, I've created a VIPM package under user.lib. Here's the first problem:
   • From what I understand (please correct me if I'm wrong) .NET loads from application subdirectories, then GAC. This means that any decencies that are installed under user.lib are not found because LabVIEW considers the project to be the application.
   • I hacked around this problem by copying all dependencies locally to the project. To me, this isn't optimal to require every project that uses this library to copy every dependency locally. It leads to a lot of mistakes when they upgrade but don't copy locally.
   • I would think there is a way to tell the DLL to find decencies in it's own directory. I have only found ways do this are by explicitly naming each dependency/location in a codebase file or by latching into the .NET event that triggers on an assembly load fail. Neither of these feel optimal to me.
   • Do people have a way around .NET's method of finding dependencies?
3. Another thing that happens when I first install the VIPM package. Every VI that calls the dlls are broken. If I CTRL+click the run arrow, they recompile and unbreak instantly. So something in the mass-compile by VIPM doesn't seem to work properly.
   • Have people seen this and do they have a way around the library being broken?

[santo_13]

Probably best to put it in GAC (using pre/post install/unistall actions)

https://docs.microsoft.com/en-us/dotnet/framework/app-domains/install-assembly-into-gac

[rolfk · Accepted solution]

---

@santo_13 wrote:

Probably best to put it in GAC (using pre/post install/unistall actions)

https://docs.microsoft.com/en-us/dotnet/framework/app-domains/install-assembly-into-gac

---

Yes, but note that you can only put strongly named and signed assemblies in there. Strongly named means that the assembly also needs a full version number. The whole .Net assembly loading limitation is an understandable (from a security viewpoint) necessity but also makes using assemblies from applications where you can't control the initialization of the app context rather difficult.

The .Net default app context only supports the GAC and the applications executable directory. Since adding .Net assemblies to the LabVIEW executable directory would cause an unmaintainable mess in the long run, LabVIEW adds instead the project directory as an additional custom location to the app context.

And yes, even if you could control the actual app context directly in LabVIEW, things are not solved. .Net has many exceptions and machine or configuration file specific hints can override the behaviour in hard to predict ways.

[JW-JnJ]

Thanks for the info. Unfortunately most of the libraries (things my library are dependent on) are still in development and probably not strongly named/versioned/signed. I might be able to sign/version mine, but it seems the dependencies are still a problem. So, it looks like I'm stuck with local copy in each development project.

Thanks for the clarification.

[JW-JnJ]

One more question, do ALL of the assemblies have to be strongly named to be in the GAC, or just the one LabVIEW directly calls/references?

[rolfk]

---

@JW-JnJ wrote:

One more question, do ALL of the assemblies have to be strongly named to be in the GAC, or just the one LabVIEW directly calls/references?

---

Yes, it has nothing to do with LabVIEW. .Net only lets you install strongly named assemblies into the GAC.