Problem with .NET dlls (Thorlabs Kinesis) when building executable

[LMKaleido]

Hello

I am building a program for an application that includes motion control using Thorlabs kinesis drivers.

Everything is working as intended in the developer environment, however when I attempt to build an executable from my project I cannot get the motion control to function.

After researching I came upon some threads that suggested keeping the Kinesis dlls in the same directory as the project and I am doing that, as well as saving the dlls in the root application folder when compiling the executable. 

After moving the dlls to the root directory the .Net containers show as "disconnected", where before they did not seem to initialize at all. However the program still cannot connect to the stages properly.

When running the exe I get the error shown in the screenshot attached. If anyone has experience compiling a program using Kinesis drivers, or just an idea of what I am doing wrong I would appreciate some help.

[tyk007]

Without code it limits our ability to help. So some ideas:

1. LabVIEW version? OS version? Framework versions? Even kinesis driver version?
2. Did you add or modify (now or previously) the LabVIEW.exe.config file for dev support for another .NET framework? If you have, then your built application needs the same since it hosts its own copy of the runtime. You can just copy the file and rename to suit your executable filename.
3. Are *all* the kinesis assemblies in the built application folder? Not just the ones you are using? So that any transistive dependencies can be resolved.
4. Have you tried looking over the Fusion log (eg. here) or checked your event viewer to see if there are any binding errors?

[LMKaleido]

Thank you for the answer

1. LabVIEW 2016, 64 bit, windows 10, Newest version of 64 bit kinesis (1.14.9)

2. I have not modified the LabVIEW.exe.config file

3. Yes, all the kinesis files are in the built application folder, I have the application builder set to always include them all (from the virtual folder I use to keep them organized)

4. No I have not tried that, and it seems like I do not have access to the Developer Command Prompt to run it, I will look into whether or not I can gain access.

I cannot really share the code I am working on, but as I said the code seems to work fine in the development environment, only after compiling do I have issues, and as far as I can tell only with accessing the Kinesis dlls correctly.

[ikaiser]

---

@LMKaleido wrote:

I cannot really share the code I am working on

---

Can you maybe share a minimized example that shows the problem? A project just containing one VI having that part of the UI resp. the .NET container code and nothing else?

The Kinesis software seems to be publicly available (bottom-most here, right?), so there should not be a licensing problem with is.

[LMKaleido]

I wanted to made a small example using my stage initialization sub VI and, and now that works when compiling to an executable, so I am further confused as to why it does not work in my main program.

I include the dlls in the same way and the .NET containers on the front panels are the same, the first thing the main program does with them is just to send the resource into the initialization sub vi, which is the same thing that the example does, and then it gives the error above.

Obviously there must be some difference somewhere, but I haven't been able to find it. I tried copying a new set of the dlls to my project folder and re-linking the .NET containers. I also tried moving all the sub VIs that use the dlls out of a sub-folder and into the main directory of the program. Everything still works in development mode, but not when compiled, giving the same error as before.

[LMKaleido · Accepted solution]

It seems like I have solved the problem, although I am not quire sure why it works.

What ended up fixing it was moving the terminals of the .Net containers out of my state machine, such that they are accessed right away when the program runs. It looks a bit more messy than I would like, but at least the program functions.

[ikaiser]

The solution / possible issue you found sounds weird indeed. However good to hear that you found a solution!