NI Package Management Idea Exchange

In the "NIPM Era", removing all NI Software is very tricky.  First, you run "Add/Remove Programs" from Windows, go to NI Software, and try to get it to Remove All (this sometimes takes more than one pass, as you might have forgotten to ask it to remove updates).  This, in turn, invokes NIPM which does all the work -- NIPM itself "shows up" in the list of files, but cannot be selected (for obvious logical reasons).

Once everything is gone, NIPM still shows up in Programs and Features, but now the "Remove" checkbox is not disabled.  If you select it, you get Dire Warnings, but this is the only way to remove the "last" piece of NI Software (except when it isn't, but that's another story).

It would be nice if this process could be simplified.  One way to do this is to have NIPM detect that you have asked to remove everything except NIPM (because it is disabled), and have a Dialog Box pop up and say "Are you attempting to remove all NI Software, including NIPM?".  You could issue all the Dire Warnings at this point, and if the user chooses "Yes", you could do the appropriate two-step removal process, first removing "everything else", and when done, removing NIPM.  I realize that software removal, like software installation, sometimes requires a Reboot and "post-boot-up" code to "clean things up", but am confident that NI could figure out how to do this safely.

Bob Schor

It would be nice if NI Package Builder could detect and prevent Windows path length limitations. Since where a package solution is built and where it is installed can be different, they typical building of the folder structure to be packed can run into the Windows 260 file path character limit. I would like if NIPB could detect that this will happen and relocate the packing folder automatically to avoid the issue. I would recommend a warning is issued; also, I have no issue that it might take longer to build as it would try and fail then redo in a new location.

Example:

When installing any package from ni, they are auto registering feeds for themselves and their dependencies. It will be good to add to feature so that when configuring and building a package, we can also specify a feed name and uri. The package will automatically register the feed when installing it, just like package from ni does. 

There is really no good way of auto-register a feed when install the package. NIPM API will stuck when running as an post install executable. The executable will be able to execute with no issue when run not at post install. The other way is to directly manipulate with the nipkg.ini which should really be avoided from end user.