LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Good time to run programmatic NI package update?

I just wanted to get some input if anyone had ideas on automatically checking for NI Package Updates. When the user runs an application, I want it to automatically check to see if a newer package (.nipkg) exists. To do this, we can use the NIPM API Beta.

 

What is the best way to incorporate this into my application? I am thinking of having the update check run first as kind of an application launcher. Then if an update is available and the user accepts the install, it will update the package and close. If no update is installed, the application will launch.

 

I think this will work, because the application will launch the command prompt installer and close very quickly, leaving the executable available to be updated. But, what would happen if the package is updated while the executable is still running?

 

I found the NIPM API a little lacking in 2 features. First, "Get Versions" is supposed to return an ordered list, from highest version to lowest, but I did not find this to be the case, so I have to find the highest version from the list. Next, installing the package requires running the command prompt as an admin (on my Windows 10 machine), so using their provided "Install Package" did not do anything, you can see the run as admin version below.

 

Thanks for your thoughts! Below is a picture of the code, but if you have LV 2016 you can download the attached zip file to play with it.

 

package update.png

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

But if the user is running a compiled executable what's the point of checking if there is an update to a source code package?

  • Unless...
    • Users are running LabVIEW programs from the development environment
      • Which they shouldn't be
    • The user is expected to install the updated source code toolkit and then compile a new executable
      • That's your job as a developer 
========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 2 of 7
(2,634 Views)

Hi RTSLVU,

I think you are thinking of VIPM (.vip) packages. NIPM (.nipkg) are used for deploying executables (and not source code at least for now). NI recommends to continue to use VIPM for source code, but use NIPM for executables.

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

Ah... Okay by bad. I was thinking VIPM.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 4 of 7
(2,621 Views)

Well, it turns out running a package update while you are running an executable from that package is no good. NIPM will think that it updated, but in fact the executable was not updated.

 

I have decided to create a separate executable which looks for updates. It can check if the original application is running using the tasklist command, and tells the user to close the application before trying to update. It kind of runs in the background using the ini key "HideRootWindow = True". I have also used the ini key "allowmultipleinstances = TRUE" since this executable is on the network and could be called by several applications at once.

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

@Gregory wrote:

 

I have decided to create a separate executable which looks for updates. It can check if the original application is running using the tasklist command, and tells the user to close the application before trying to update.


I really think this is the only real way to accomplish this, and it is the way I've seen it done in the past with things like the deploy toolkit.  Still it might be a bug with NIPM that it thinks the package was updated when it wasn't, and couldn't be, because that application was running.

0 Kudos
Message 6 of 7
(2,553 Views)

Just a quick update now that we've been using NIPM for a couple years. Running the update from my separately compile "Package Updater.exe" worked pretty well, until there is a NIPM update. On my development PC I open NIPM pretty regularly and update when a new version comes out. But, if I then build a package, the installation fails on a lab PC running an older version of NIPM. I found you can get (not officially supported) version info from the package and check for NIPM compatibility, but rather than reinvent the wheel, I changed the "Package Updater.exe" to just pop up a prompt to either open NIPM or update later. 

 

It still feels like a slightly more professional update experience than telling someone to go run "...\volume\setup.exe"

Message 7 of 7
(1,941 Views)