User types/control (and other dependencies) not found after installation

[michele.santucci]

I'm trying to create an installer for a LabView executable application.

This's the project structure:

The installer MAN_TEST_UI_Admin should install the three executables (CreateLicense, MAN_TEST_Shell*) and related packed libraries.

MAN_USER_TYPES_Library is a packed library containing three user defined types.

The installer correctly builds. I tested the application on a clean Microsoft Windows 11 Enteprise Virtual Machine.

Just after the setup finishes I try to launch one of the MAN_TEST_Shell*.exe but I got this:

If I select MAN_USER_TYPES.lvlibp I got this:

File not found????

How can I specify to use the MAN_USER_TYPES.lvlibp ? I need to change something into caller VIs before compilation?

Last but not least some subVI in the project depends on TQLP_32.dll that's listed between the dipendences of both MAN_TEST_Shell*.exe 

but it's not installed (it should go in C:\Windows\SysWOW64\) and this's the result:

There's a way to set the installer to properly satisfy this dependency (or at least to report an error)?

Please note that every other dependency on external components such as custom built .NET Assemblies are correctly identified and resolved into installation.

PS I'm using LabView 2013 SP1

[tst · Accepted solution]

For packed libraries, I haven't actually used them myself, but my understanding is that the way to work with them is to have a separate project for you lvlibs, build them into PPLs in that project and then use those PPLs in your code. I expect that's the issue you're having here (your EXE is searching for a VI in a .lvlib, although it's not clear to me why that library simply wouldn't be included in the EXE, which it would be by default if you have  a static link to it from something else which is included in the EXE). Note that this can have various complications (and I'm not sure if there are no significant issues with PPLs which were resolved after your LV version), so I would suggest looking up some materials and starting testing from simple applications to understand the behavior.

For the DLL, if you have some kind of installer for it, it's probably best to configure that to run as part of your installation, because that way it can install and configure everything as needed. It can be additional dialogs, or some installers have command line switches to run in quite mode.

If for some reason this is not feasible, the Destinations page of the installer build spec does include the Windows folder and I'm guessing you can add the relevant DLLs to your project and configure them to go in the relevant folder, but that sounds riskier (permissions, path changes, etc.).

[michele.santucci]

---

@tst  ha scritto:

For packed libraries, I haven't actually used them myself, but my understanding is that the way to work with them is to have a separate project for you lvlibs, build them into PPLs in that project and then use those PPLs in your code. I expect that's the issue you're having here (your EXE is searching for a VI in a .lvlib, although it's not clear to me why that library simply wouldn't be included in the EXE, which it would be by default if you have  a static link to it from something else which is included in the EXE). Note that this can have various complications (and I'm not sure if there are no significant issues with PPLs which were resolved after your LV version), so I would suggest looking up some materials and starting testing from simple applications to understand the behavior.

For the DLL, if you have some kind of installer for it, it's probably best to configure that to run as part of your installation, because that way it can install and configure everything as needed. It can be additional dialogs, or some installers have command line switches to run in quite mode.

If for some reason this is not feasible, the Destinations page of the installer build spec does include the Windows folder and I'm guessing you can add the relevant DLLs to your project and configure them to go in the relevant folder, but that sounds riskier (permissions, path changes, etc.).

---

Well I managed to fix the packed library issues in some way.. don't know why because I had to refactor the project for other reason and when I re-created the installer the problem was fixed.. anyway I misunderstood the scope of packed libraries itself now anything is clear.

Still have to fix the DLL issue but it sounds like I'll need to add the installer of the driver in some way... I still have to identify which device requires it (some TTi product I think).

Best regards,

 Mike

[tst]

---

@michele.santucci wrote:

---

... it sounds like I'll need to add the installer of the driver in some way...

---

The relevant place is in the Advanced page >> Run executable at end of installation. If you need multiple executables or command line options, you can create a batch file and run that.

[michele.santucci]

Yes the problem is to identify the driver that contains this dll... I think it comes from TTi power supply.. anyway I fixed it adding the TPQL_32.dll to the project and then 'installing' it into System folder. It works. Of course when I will get the correct driver I will install the way you suggested.