Building application using .net libraries with LabView 2017 on Windows 10

[zbartal]

Hi,

I am trying to build a LabView application that is using custom .net dlls but I am running into a problem. The application is built and runs but it seems that it is completely ignoring the calls to the .net assemblies. No errors are shown, the application simply ignores the functionality. This happens even on the development machine where the vi runs without problems in the LabView development environment and where the runtime for LabView 2017 is also installed. The assemblies are in the application folder in ./data and I also copied them to the ./ folder which did not change anything.

Is there something that I should be doing? Any help would be appreciated.

[rolfk]

This is typically due to missing dependencies. With that I do not mean the DLL assembles that you call directly bur assemblies and DLLs your .Nst assemblies call.

The assemblies you call directly. LabVIEW can detect at compile time and by default it automatically takes them into the build and puts them in the Data folder if you don’t change the location for the Support directory in your build. That path ould be anything as long as it stays the same relative to the executable. LabVIEW stores the relative path in the compiled application and will find it at runtime even if you change the Support location path to a longer or multilevel subdirectory.

But once LabVIEW passes that path to the .Net CLR to load that assembly, all LabVIEW can do is to wait for Windows to finish loading everything and report pass or fail.  Windows sees the path, looks at the assembly and tries to load it but first it tries to load all the dependencies the assembly claims to have in its import table. And for .Net DLLs Windows is very picky. It will only search in the GAC, the applications root folder and any additional directory added by an administrator to the search configuration, which is usually none. Now if that fails Windows will report an error to LabVIEW and if you do proper error handling by not just ignoring errors in the error cluster you  will see that error.

But a DLL/assembly can also state that some of the dependencies are delay loaded or not inform Windows about it but try to load the dependency itself the first time a function makes use of it. The same search limitations exist for delay loaded DLLs. If Windows (or the assembly itself can’t find it the function could simply silently fail if not properly handled in the DLL. But it could be worse and simply crash when trying to jump in the non existing function.

What extra dependencies an assembly has and how to install that properly on a target application SHOULD be part of the documentation for your assembly, but most programmers run quickly away once their assembly starts working and such information very seldom makes it into the documentation, if there is even one to start with.