.NET DLL Locations with Other DLL References

[BradD2]

I have a .NET DLL that I have utilized in a project and have successfully been using. I believe it references other DLL's as the example VI only works when I have the .NET DLL and additional DLL's in the same folder all inside the project folder. All is well.

Now if I don't load the project and just that example VI, LabVIEW hard crashes (generic 1172 error). It only works if I move the DLL's to the location of that example VI. I have seen in other posts that LabVIEW can load the .NET DLL but any DLL references inside the .NET DLL (apparently even in the same folder as the .NET DLL) won't work. The VI and all DLL's appear to have to be in the same folder unless you load the entire project.

I tried installing the .NET DLL into GAC but I believe it crashes because I believe it can't find it's referenced DLL's (nor do I know where to but the non-referenced DLL's)

Is there any way to get this to work with the example VI without putting all the DLL's in the same folder as the VI (short of building a LabVIEW executable)?

Thanks,

Brad

[tyk007]

I assume you've read this: https://docs.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies. LabVIEW adds to Fusion probing paths when using a LabVIEW project. This link here is an oldy but a goody: http://detritus.blogs.com/lycangeek/2005/03/psst_can_you_ke.html

If you are running in the dev environment, you basically have these options:

• Use the GAC for all referenced assemblies. All assemblies need to be signed to be loaded in the GAC for security reasons - this might be why you can't do this with your specific case.
• Use the same folder for all referenced assemblies - same folder as your VIs that call them.
• Use a LabVIEW project.
• Configure the Fusion probing paths with a config file - ie. LabVIEW.exe.config. This is not a maintainable solution in dev since this file is global to the LabVIEW dev environment; but a reasonable one for built applications (executables).

I strongly suggest going the Project route and, if you are passing this along to another developer, let them know to work through the project. It will save you a lot of hassles in the long run.

If you want more specific ideas, post your project and examples.

[BradD2]

I appreciate you getting back to me and I apologize for not getting back sooner. I have a feeling there are many dependencies within the DLL code that may be muddying the waters. I have attached a very basic project where I just call a constructor node.

The project has the DLL's in sub-directory (\DLL) presently. I have done the following:

Launch the project, launch Ex1.vi, and run it successfully.

Close out LabVIEW completely.

Launch Ex1.vi and run it, failed.

Move DLL's to same directory as Ex1.vi

Launch project, launch Ex1.vi (see notifications that it see's DLL's in new location) and run it successfully.

Close out LabVIEW completely.

Launch Ex1.vi and run it, successfully.

Close LabVIEW completely.

Launch LabVIEW.

Select Ex1.vi from the shortcut menu and run it, failed. (Obviously I can work around this by not launching in this manner but I figure I would mention it)

I have attached a few logs of the fusion logger as well.

I tried installing just the three DLL's referenced in the log into GAC but without the supporting DLL's it doesn't work. I verified this by creating a project with just those three DLL's local without GAC and couldn't even create a constructor node unless all DLL's were present.

If I have to keep them in the same directory as the VI that calls them, I will. I am just looking for a cleaner solution. Where we don't launch projects or an executable on the manufacturing floor, I m trying to come up with the best solution. Thanks for the help thus far.

Brad

[tyk007]

For your use case you have a number of managed .NET assemblies that reference the unmanaged Win32 libs (all the "fe*.dll). This is why just putting the managed assemblies into the GAC didn't work. A possible, hacky, work-around is putting the unmanaged libs into the %system32% folder (they all appear to be 32-bit so you might need to chuck them into the SysWOW64 folder instead if your OS is 64-bit - can't remember the P/Invoke rules off the top of my head).

But even if this works, it's still a setup issue for another developer / user, albeit one that you could probably automate via batch file / powershell etc. If there are new versions of your dependency  that you want to deploy over time then this presents a head-ache (similar to what the GAC was designed to prevent).

All the behavior you are describing is correct, expected, and follows the what all the docs (NI and Microsoft) describe. Albeit inconvenient in your case.

My suggestions is to either live with a bunch of dlls in the folder or use a project. Future support will be a whole lot easier and its just a case of copying a folder for deployment or upgrades.

[Kyle97330]

I've found a workaround that sometimes works:

1. Run your program, get error 1172.

2. Find the file name of the DLL that's referenced but can't be found.

3. Create a .net block diagram constant (of any class).

4. Right-click said constant, choose "Select .NET class", then the "Browse" option.

5. Select the file name that's referenced but can't be found, from earlier.

6. Choose literally any class from that DLL to assign to the constant.

7. Run again.  If a different DLL is missing now, repeat as needed.