LabVIEW
Problem with building exe. of Thorlab Kinesis motor included .NET container
Solved!
Hello everyone
I am working on building exe. from a project that include Kinesis .NET container(KDC101 control).
It works fine on development environment just like others, but I can't run with the exe. which build from project. system will display
(in the exe.)
I guess it the problem with the .NET container, because I create a new simple vi without the .NET container and it works fine on exe. (the vi with .NET container wasn't included in building application)
In order to investigate it easily, I use Kinesis motor example vi (Name: Kinesis - KDC101 - Move Absolute)with .NET container.
and only two dll. included in this vi.(two dll. show in figure below)
(The front panel of vi in development environment)
(The block diagram of vi in development environment)
I think the problem of .NET framework is not involved in, because the interface in container will not pop up if the .NET framework problem had occurred in development environment.
So far I'm still haven't find out where the real problem is, but I guess the potential problem may be the dll. of the Kinesis when the Labview building exe.
Application of properties when building application exe. :
Labview version: 19.0.1f3(32bit), professional development system.
Kinesis version: 1.14.23(Build 16838) (32bit)
My laptop: Win 10 (64bit)
Hi Geocactus,
Have you found a solution yet?
You are missing a few steps.
1. You must include all DLLs that are called by the main Thorlabs.MotionControl.Controls.dll. There is no way to know which DLLs are required so I suggest you copy all the DLLs from the Kinesis folder and delete one at a time. As and example, here's a list of files that a filterflipper requires:
2. You need to copy all DLLs to the same folder as your executable. For some reason, Thorlabs created their DLL in a way that it can only
find the required private DLLS in the directory of the running executable.
This should do the job. Let me know if you have any questions.
Eric
@Pitts-burger wrote:
2. You need to copy all DLLs to the same folder as your executable. For some reason, Thorlabs created their DLL in a way that it can only
find the required private DLLS in the directory of the running executable.
This should do the job. Let me know if you have any questions.
That’s simply how .Net works by default as designed by Microsoft. The other default option is to install all those DLLs to the Global Assembly Cache but that is something the manufacturer should provide an installer for. You should never add .Net assemblies to the GAC yourself!
@Pitts-burger wrote:
Yeah, that is how LabVIEW finds the main DLL Thorlabs.MotionControl.Controls.dll. But what I meant to say is, that DLLs then calls other DLLs that need to be in a specific folder. For some reason, it is not enough that they are all in the same folder. They need to be in the same folder of the main executable.
And that is exactly what I wrote! 😀LabVIEW is very able to load an assembly DLL from wherever it was stored by the application builder since the VI is update with the new path to the DLL during application build. From there it is all out of the hands of LabVIEW and the Windows .Net loader handles the rest including loading all dependencies. And the .Net loader by default only checks the GAC and the executable directory for these dependencies.
I build the application with all the dll. file in "always include".
After the build process done, I moved the dll. files which in "data" subfolder to the folder which the Application.exe located:
Then this is the result:
The interface of the KDC controller finally appeared in exe.
Thank you very much
@geocactus wrote:
I build the application with all the dll. file in "always include".
After the build process done, I moved the dll. files which in "data" subfolder to the folder which the Application.exe located:
You don't have to do this manually. By adding another custom destination to the Build Specification that points to the same directory as where your executable is, you can then assign that destination to the files in question and the Application Builder will do the rest.
