How to configure build so that a dynamically loaded lvclass in a built EXE can find dependent .NET assemblies

[bodnerks]

I have application that uses .NET assemblies and that works in the development environment, when the lvproj is open, but does not run when built into an EXE. I’d like to know if there’s a way to ensure that an lvclass, that gets loaded at runtime, will find the .NET assemblies (DLLs) it requires. In my development environment, I’ve followed the rules in LabVIEW Help for selecting the locations of the .NET assemblies (DLLs); i.e., the .NET assemblies are in a subdirectory where the lvproj resides and all the VIs that use the .NET control are added to the lvproj. http://zone.ni.com/reference/en-XX/help/371361L-01/lvconcepts/net_defaults/ http://zone.ni.com/reference/en-XX/help/371361L-01/lvconcepts/loading_assemblies/ Here is my folder structure: MyProjects\ BFProject.lvproj ThorDotNETAssemblies\ (the .NET assemblies (DLLs) reside here) MySource\ MyDrivers\ ThorMotorDrivers (VIs that use the .NET control reside here) MySubsystems\ (the lvclasses reside here) 1AxisMotor-generic.lvclass 1AxisMotor-Thor.lvclass 1AxisMotor-MForce.lvclass I’ve added all the VIs in MyDrivers\ThorMotorDrivers that use the .NET control into the lvproj (auto-populating folder). I’ve also added all the lvclasses in MySubsystems to the lvproj – these classes have methods that call the driver VIs in ThorMotorDrivers. Now, in the development environment with the lvproj open, I can successfully run the methods of the 1AxisMotor-Thor.lvclass. However, when I close the lvproj and open the lvclass by itself, it can’t find the .NET control and the VIs are broken. The .NET container on the front panel says “Control could not be loaded”. [When the class opens I can see that LabVIEW has to go through the search paths to find the DLLs, but it does not complain that it can’t find them.] For the built EXE I use an XML configuration file that specifies which of the 1AxisMotor lvclasses to load at run time based on the hardware configuration; i.e., I can use any one of the child classes of 1AxisMotor-generic.lvclass. However, when the application goes to load 1AxisMotor-Thor, it seems it can’t find the .NET assemblies – the LabVIEW run-time engine throws error 1498 saying the library (1AxisMotor-Thor.lvclass) has errors and needs to be fixed. [I’ve also seen Error 7 that the 1AxisMotor-Thor.lvclass file cannot be found during my trial-and-error attempts at fixing the problem.] Is there a way ensure that the dynamically loaded lvclass will be able to find the .NET assemblies? Is there a way to test that the lvclass will work without having to make the build, which currently takes 3.5 hours? I’m using 32-bit LabVIEW 2014 SP1 on Windows 7 64-bit. In the build spec in the lvproj I’ve specified that the entire ThorDotNetAssemblies folder always be included in the build, and that the destination for all contained items is the data folder (support directory) – my thinking here is that the LabVIEW application builder may not be finding all the dependent DLLs so I make sure to include them all. [I did use dependency walker to try to find out which DLLs specifically are needed, but then just decided to include them all.] In the build spec, all the ThorMotorDriver VIs and all the lvclasses are always included and are specified to be put into the .exe destination location. I’ve also set the search paths for VIs in the Tools > Options > Paths > VI Search Paths to include the folder where the .NET assemblies are. The .NET assemblies come from ThorLabs – their Kinesis 32-bit software for 64-bit windows: https://www.thorlabs.com/software_pages/ViewSoftwarePage.cfm?Code=Motion_Control&viewtab=1 https://www.thorlabs.com/Software/Motion%20Control/KINESIS/Kinesis-Labview.pdf The Kinesis software has been installed on the LabVIEW build computer and the computer that runs the EXE. I’ve also tried adding the ThorMotorDrivers folder and the ThorDotNetAssemblies folder to the lvclass, but that didn’t work; and, in fact, I ended up with a corrupted lvclass file – LabVIEW couldn’t even open it. Based on NI forums feedback (e.g., Built exe not referencing correct .NET assembly locations: http://forums.ni.com/t5/LabVIEW/Built-exe-not-referencing-correct-NET-assembly-locations/m-p/2488890... and Creating drivers using an unsigned .NET framework and distributing through VIPM: http://forums.ni.com/t5/LabVIEW/Creating-drivers-using-an-unsigned-NET-framework-and/m-p/3213904#M93... I’ve also tried creating exe.config files to specify the version of CLR to use – no luck. I did verify that the .NET framework versions are all installed – 2 through 4.5. [How does one set up an exe.config file when there are a number of other .NET assemblies corresponding to other hardware, each potentially targeted to run on a different version of the CLR?] Worst case scenario is that I abandon the .NET assemblies and re-do all the driver VIs using ThorLabs’ ActiveX control; but I’d rather use the .NET assemblies since I’ve already completed the code and tested it … in the development environment anyway. Thanks.

[Alexander_Sobolev]

>>  In the build spec in the lvproj I’ve specified that the entire ThorDotNetAssemblies folder always be included in the build, and that the destination for all contained items is the data folder (support directory) 

Can you try to manually copy thorlabs dlls into support directory? From manual I see that there is drivers folder and labview can put all dlls into one folder that is not good - it breaks internal dependencies.

Also try to add custom destination directory for these dlls and set "Preserve disk hierarchy" in it's settings.

Do you have "Use LabVIEW 8.x file layout" off in build settings (advanced)?

Check additional exclusions settings, they can also matter.

[bodnerks]

Apologies for the poor formatting of the original post -- it's difficult to see the folder structure.

Here is my folder structure:

MyProjects\

               BFProject.lvproj

               ThorDotNETAssemblies\

                              (the .NET assemblies (DLLs) reside here)

MySource\

               MyDrivers\

                              ThorMotorDrivers (VIs that use the .NET control reside here)

               MySubsystems\ (the lvclasses reside here)

                              1AxisMotor-generic.lvclass

                              1AxisMotor-Thor.lvclass

                              1AxisMotor-MForce.lvclass

As an update, since someone sent a private message inquiring if I had found a solution:  No, I was not able to get the Kinesis .NET assemblies to work in the built application.  I ended up just creating a new lvclass that used the APT ActiveX control instead and that worked fine in the built and installed application.  I switched to the ActiveX control simply because I was out of time and needed to move forward.  That said, I haven't had time to go back and solve the problem with the .NET assemblies.  My next approach to try would be to put all the source code and DLLs into a single folder (lvproj, lvclasses, driver VIs, .NET assembly DLLs, etc.) and specify in the build that everything go into the EXE or the EXE's folder (e.g., not the support (/data) directory where DLLs would normally go).  My project is quite large (> 10000 VIs) so changing the folder structure at such a late stage of the project would be undesirable -- ' just haven't had time to try it.

[AnalogKid2DigitalMan]

Fluoresence imaging application by chance?

-AK2DM

[mjhakkar]

I managed to get my K-Cube working by copying all (~120) Thorlabs/Kinesis dlls to root folder of the exe.

[BigShotEngineer]

---

@mjhakkar wrote:

I managed to get my K-Cube working by copying all (~120) Thorlabs/Kinesis dlls to root folder of the exe.

---

This is the solution.  I too copied all the .dll, .h, and .lib files into the same folder as my exe and it works!  I also did the .exe.config thing from this "Knowledge" Article.  My original problem was compiling in app builder, then the compiled exe has broken arrow after app builder make into exe.  

I suppose I could try one by one to find out which files are actually needed.  Directly loaded .NET assemblies in normal labview were:

1. Thorlabs.MotionControl.Controls.dll
2. Thorlabs.MotionControl.GenericMotorCLI.dll
3. Thorlabs.MotionControl.DeviceManagerCLI.dll
4. Thorlabs.MotionControl.PrivateInternal.dll

Apparently, it needs many more than that to work.  Thorlabs labview support is truly a piece of work ����.