LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

How to deploy a RT DLL and all its dependent support DLL's automatically

Hi there,

 

I have a workspace with several real-time DLL projects:

ControlManager: the DLL with the RTmain function, so it can function as the Startup DLL

RemoteControl, MotionControl, DataManager, EventLog: support DLL's with DllMain supplying needed functionality for the ControlManager.

 

When I manually copy the support DLL's and then Run->Install Program...... the ControlManager, my RT-Target gets all the files needed and works using my latest DLL's, without any explicit run-time loading of any DLL.

 

So far I haven't found any way to make the "Run->Install Prog....." automatically update my support DLL's although I have included the .lib files for each support DLL in my ControlManager project.

The auto-increment option for the version info doesn't help either, worse yet; it seems to increment after the install and nags about the project release configuration being out of date when  I want to install the DLL again, forcing me to build again , thereby incrementing the version again (vicious circle).

 

Does anybody know why LabWindows/CVI does not seem to be willing to do this not so uncommon task for the lazy programmer and save him the bother of having to manually update his support DLL's?

 

Thanks in advance,

Aart.

 

0 Kudos
Message 1 of 3
(4,108 Views)

The Run>>Install Program to Real-Time Execution Target option behaves very similarly to when you start debugging a RT DLL. There is currently no mechanism to detect changes in loaded dependency DLLs or to force an update if those dependency DLLs are already present on the target. I will file a request to have your situation considered.

 

For now, you could write a simple batch file to ftp your support DLLs to the target, then add it to the Tools menu via Tools>>Customize. Of course this still requires you to do two separate things each time you want to redeploy your application, and your batch file will have to be updated if you change target machines or source paths. It may still be convenient for you though.

 

Mert A.

National Instruments

 

 

0 Kudos
Message 2 of 3
(4,097 Views)

Hi Aart,

 

It turns out that my previous response was incorrect. If you follow a couple (unofficial) guidelines, CVI does do a good job of finding and copying your project's DLL dependencies as needed:

 

  • On the host machine, your DLL dependencies should be in the same directory as your main DLL (in your case, ControlManager). If you don't want those projects to build directly into that directory, you can copy the built DLL in a post-build step (Build>>Build Steps...).
  • Do not manually FTP your support DLLs to the target RT system. Let CVI manage them for you. If you have manually FTPed them to the system directory, delete those files.
  • Before re-installing (updating) your application on the RT target, use Run>>Manage Files on Real-Time Execution Target to remove the previous batch of files.

 

The reason for the first guideline is that CVI only looks for your support DLLs next to the main DLL. If it can't find them there, it won't be able to FTP them to the RT target.

 

The reason for the second guideline is that CVI first attempts a LoadLibrary on the main DLL on the target before transferring any dependency DLLs. If the main DLL loads successfully on the first try -- which is the case if your support DLLs can be found in the system directory -- then CVI assumes it does not need to copy/update any dependencies. If the DLL does not load, CVI determines its missing dependencies and FTPs the DLLs over.

 

As for the third bullet point, the installation process puts the DLLs in the NI-RT\CVI, whereas just debugging an RT project puts the files in NI-RT\CVI\temp. The temp subdirectory is not part of the system's DLL search path, but the parent CVI directory is. So if your dependency DLLs can be found in that directory, your main DLL will load on the first try, and CVI won't copy over the newer versions of the dependency DLLs.

 

Hopefully these guidelines will help you for now. We'll try to make the experience better in a future release.

 

Mert A.

National Instruments

0 Kudos
Message 3 of 3
(4,002 Views)