Problem running an labview create .exe that uses .net

[Terry_S]

I have a application that I have created that is using .net  supplied from the camera manufacture.  I have created an installer and installed it on a new Windows 11 computer.  When I try to run the application I get a message asking for the location of the dll.  If I select the .dll in the displayed control, the application will load but it is broken and not running.

The manufactures instructions for distributing an application are to include some files

My installation does the following. On installation a main folder is created that has the application .exe and a data folder that contains the .dll's

Using PowerShell I checked the version of .net that is require for the TIS.Imaging.ICImagingControl35.dll and it is 4.0.3031.  The version of the runtime that is on the new computer is version 4.8.

I have installed this application on the same machine which is a Windows 10 computer and I have no issues with running it.  So there is something that is not being setup correctly.  I even when so far as to install the sample application from the manufacture on the new computer and it runs with no problems (I believe it was written in C).

Any help on finding out why my application cannot find the required .dll would be appreciated.

[Kyle97330]

Try changing your build specification so that instead of having two paths ("C:\RFS\HPM\" and "C:\RFS\HPM\data") it just has one ("C:\RFS\HPM\").  This would be under the "Destination" options of the build specification, just have both the EXE and the support directory both pointing to the same directory.

[Terry_S]

I changed my build so all the files are being installed into the same directory as the .exe.  I am still getting the same messages asking to find the .dll.  The only change is the starting point is now the main directory and not the data directory.

Terry

[rolfk · Accepted solution]

It is definitely a dependency problem. One of those DLLs depends on something that is not installed on your computer by default.

I would use Dependency Checker https://github.com/lucasg/Dependencies to look at all the different DLLs and what binary dependencies they try to load. Preferably on the computer where you see the problem. It is either a missing DLL or maybe a version conflict with one of the DLLs that LabVIEW itself uses. Depending on which LabVIEW version you use it has its own Visual Studio Runtime dependencies and not all of them are SxS (side by side) loadable.

[Terry_S]

Here is what I found was the problem.

The manufacture supplied 32bit and 64bit versions of the .dll.  I was using add the 64bit version to the build, but my application was created using the 32bit version.  Once I used the correct the version of the .dll, everything worked good.  I was able to put the .dll's in the data folder.

What I find confusing is when you insert a .net control into a container, what version is the control located in the list.  Is the list of controls based on Labview 32bit vs 64bit or the computer OS?

[rolfk]

The problem with .Net assemblies is that they can be either binary x86, x64, and likely also ARM, byte code MSIL/CIL or mixed mode. And the interface information is located in the type library, which is mostly byte independent. So there is no easy way to tell what sort of .Net library you have from a high level Visual environment like LabVIEW.

To populate the property and method nodes, LabVIEW uses the information of the type library, to execute it it tries to invoke the exported interface and that could or could not succeed depending on the binary compatibility of the actual code inside the assembly.

And in your case the assembly is most likely a mixed mode assembly, that means partly MSIL/CIL byte code and partly compiled code and the dependencies are normal compiled Windows DLLs