LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

EXE works on Development Computer, will not find DLL on Test Computer

Solved!
Go to solution

I have a DLL that the manufacturer requires me to use to access their database.  They provided the DLL and the .h file, and I used LabVIEW 2017 to import the DLL functions (Init, Log in Dialog, Get SN, and Exit).  I was able to successfully build a test EXE and Installer for the testing PC, and the test program still runs well; including using the DLL to access the MFR database.

 

I have attempted to build another test for a different product, using the same VIs to call the DLL.  The EXE will run just fine on my development computer, but when I try to run it on the test station PC, I get the following message:  LabVIEW: Resource not found.  TrkSysMySQL.DLL  An error occurred loading VI 'VIs.lvlib:Log In Dialog.vi'.

 

The DLL is in the same directory for this program as it is for the working test program.  I have verified that the library node is calling the correct location (see images).  The DLL has been placed in the SysWOW64 and System32 directories, as well as the data and application directories, and the directory listed in the images below.

 

What am I missing?  Why will the EXE work on my development PC and not the deployed PC?  Are there step-by-step instructions on how to build an EXE with a third-party DLL?  What is the process for creating the VI wrapper (place desired DLL in directory X, make sure the Configure page for the library node shows Y), and then building the EXE (make sure the DLL is listed in this column, and the calling VIs placed in this column, etc)?

0 Kudos
Message 1 of 7
(2,488 Views)

I'm not sure what the difference between your two programs is, but from the screenshots (by the way, typically better to attach images than docx files containing only images - not everyone has Word) I'd suggest you might want to try adding the DLL file to the "Always Included" box, and then on the Destinations page you should be able to select (perhaps this is the default) something like "Data", which will by default by a subdirectory alongside the exe file.

 

This way, the LabVIEW compilation process will update the path to use the correct value (since you're connecting the DLL directly and not using the "Specify Path on Diagram" option.


GCentral
0 Kudos
Message 2 of 7
(2,447 Views)

What type error are you getting, If you post the error that would be helpful for helpers to give a conclusion

0 Kudos
Message 3 of 7
(2,429 Views)

Please include the vi, which is calling DLL, in always included section during Build.

I hope this is missing in the screen shot

AB
Kudos are Accepted
0 Kudos
Message 4 of 7
(2,426 Views)

First, thank you for all of your suggestions!  My future posts will be image files vice the document of image files.

Second, I have added the DLL to the Always Included list, and the attached error message was generated (Error 1A and 1B to see the complete message).

 

For additional reference:

The DLL is in the directory C:\Autani\

     This is where the DLL is located on the Test Computer

     This is where the DLL is located when using the Import DLL wizard to create the wrapper VIs.

For Installation:

     The application is in the directory C:\Program Files (x86)\Autani HBS\

     The data directory is C:\Program Files (x86)\Autani HBS\data\

0 Kudos
Message 5 of 7
(2,397 Views)

I included the calling VIs in the Always Included section.  I did not include the DLL file here.  After building the EXE and the Installer, I installed the program on the Test Computer.  When the program was started, I received an error, and the program did not run (front panel open, run arrow broken).  I have attached an image of the error message.

0 Kudos
Message 6 of 7
(2,395 Views)
Solution
Accepted by topic author DLJ

I ended up rebuilding the wrapper VIs, and made sure to check that they would run in any thread.  I believe that this was not checked on previous builds.  After adding all of the calling VIs to the Always Included section when building the EXE (not the DLL itself!), the program ran on the target computer.

 

Thank you to everyone who reviewed this thread and provided feedback!  I'm still learning!

 

Respectfully,

 

David Johnson

0 Kudos
Message 7 of 7
(2,364 Views)