Building LabVIEW Installers

To be honest, I’ve built basic LabVIEW installers before, but I’ve never needed to install crazy (non-NI) dependencies or write registry keys or anything “advanced.” Well, that is, until today. Here are some quick lessons I learned:

Adding non-LabVIEW files to your installer

So, in my case, I need to install a PostgreSQL server. I could do it the easy way by invoking the Postgres installer after the installation, but I’m trying to be a bit cleaner than that. Instead, I’m working from the Postgres .zip distribution and manually copying the files over. So, I add the directory as a virtual folder (snapshot) to my project and go to put them in my installer.

Bad news… You can’t bulk add the contents of a virtual folder to an installer directory; they must be done one by one.

Fortunately, there’s an easy solution: Put all your dependencies in an auto-populating folder. It can be added to an installer folder in a single step. Problem solved.

Installing a large number of files

So, Postgres, thinned down to only what I need, is still about 15,000 individual files. (Realistically, I could probably slim it more, but I don’t think the ROI is there.) So, I get them all in my autopopulating folder, and go to the “Source Files” tab, then expand “My Computer…” and wait. For about 30 minutes. Finally it all refreshes and shows up. Now I go to add it to the “Destination View,” so I highlight the folder and click the arrow. And wait another 30 minutes. This is bug number one. Then, I actually tried to build the resulting installer and this seems to create a corrupt build spec that throws errors on build. That’s bug number two.

Arbitrary files shown, not my actual application.

I opened a support request with NI and they didn’t make much immediate headway, so I went digging a bit. I CAN add .zip files that contain a large number of files, but how do I extract them? As I expected, that mechanism to “run an executable after installation” on the advanced tab also allows you to run .bat files a well. A little further digging shows that there is a powershell command (that can be invoked from a batch file) to do just what I need:

@echo off
powershell -command "Expand-Archive -Force '%~dp0\myfile.zip' '%~dp0..\dependencies'"

For those curious, %~dp0 simply returns the directory in which the batch file is located. If you just try to use relative paths, you will end up using the paths relative to the installer. I can see some clever use cases for that, but I’m not going down that rabbit hole right now.

This will take the myfile.zip located next to the batch script, and unzip it in to a folder on level up and then back down to dependencies. Note that this dependencies folder is created automatically, there’s no need to create it in advance.

I also decided to clean up after myself by removing the now unneeded .zip files. This is easily done using the rd command. The following is my complete batch file:

@echo off
powershell -command "Expand-Archive -Force '%~dp0\myfile.zip' '%~dp0\..\dependencies'"
rd /s /q "%~dp0\..\Installation Files\"

Pseudo-paths in registry values

Finally, I want to make some registry keys to set up my ODBC connector. BUT, what if my user chooses to install to a different directory? Pseudo-paths to the rescue. Instead of specifying the path to my DLL as C:\Program Files (x86)\My Program\ODBC_Connector\connector.dll I can simply put it in as [INSTALLDIR]ODBC_Connector\connector.dll and the installer will set it as appropriate. Important to note, there is no \ following the closing bracket. More details on that (and some other handy pseudo-paths) can be found in this NI KB: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019VtxSAE&l=en-US

For what it’s worth, the first post that resolved my issue was here: https://forums.ni.com/t5/LabVIEW/Installed-path-for-registry-settings-for-Installer/m-p/1172927#M510497 (Is it wrong to kudo a 10 year old post? ‘Cause I did.)

Also worth noting, keys will automatically go in WOW6432Node if appropriate. No need to hard code that in to your keys. In fact, if you do hard code it, it won’t work.

Summary

  1. Use Auto Populating folders for dependencies
  2. If you have a lot of dependencies, zip them up and unzip by calling a batch file
  3. Pseudo-paths are there if you need them.

Leave a Reply

Your email address will not be published. Required fields are marked *