NI Measurement Studio Idea Exchange

When the installer builder is called from the system shell (cmd.exe) using a command like the following:

InstallerBuilder "D:\NI Installer Builder\INSTALLERPROJECT.iip" -Build -Log "D:\NI Installer Builder\niib.log"

It spawns a background process and the application returns with a successful run BEFORE the installer is created. As the build is started in a background and a detached process; any build automation frameworks such as bamboo, jenkins, chef, etc. cannot monitor it's creation. This results in a failed operation a breaks continuous integration systems. 

As a work around I have built a light python solution that monitors for a que event; in this case a
file either being populated or updated. I am using this application to monitor the log file as a que.
The python file should be attached to this submission.

Basically:
1. InstallerBuilder is ran – begins running building process in the background
and returns successful process run before installer is constructed.

2. IndirectProcessMonitor.py is ran (max timeout and file set):
python IndirectProcessMonitor.py 300 “D:\NI_installerbuilder\niib.log”
NOTE: Probably could set it to your setup file as well

3. IndirectProcessMonitor.py returns when timeout is exceeded or que file is
created or updated.

If the NI installer builder is to be able to be dropped into any automation
frameworks this has to be fixed on NI’s end. If this bug/support is scheduled
for development I’d be interested to know as it will/should break our
workaround.

When I install Measurement Studio 2013 on a development computer, activate my Standard Development serial number and license that PC over the Internet, and build some software in Visual Studio, the Enterprise Development trial is automatically selected in the build process. After 30 days, the license expires, and the software behaves as if it is unlicensed - that is, it crashes. A Clean and Rebuild must be run to select the Standard Development license and make the software work again.  I believe that this default behavior is incorrect.  This 30 day window is often shortly after delivering the machine to a customer, so it fails on their floor right after we leave! This is not good for our reputation or for NI's reputation.

One or more of the following options would be the preferred behavior:

(1) Do not automatically enable the "Enterprise Development" trial. This trial should be deactivated by default when a Standard or Professional license is activated, and a user should be able to open NI License Manager and Activate it as required.

(2) Show a warning on start-up whenever a trial license is used. This is what LabVIEW does: upon launch of LabVIEW the user would see something like "Evaluation License - 5 days remaining".  Measurement Studio users do not see this upon launch of Visual Studio, upon building the project in Visual Studio, or upon starting the resulting software.  It would be nice if you could provide a link that would instruct users on how to deactivate the Enterprise Development license in this warning.

(3) Use the lowest possible development system. If Enterprise-only features are used and a Standard license and Enterprise trial are available, then the trial is necessary (though a warning as in #2 above would be nice), but otherwise use the Standard or Professional license. This issue has caused us some embarrassment several times. Please fix it!

The workaround, according to Michael Keane from NI (in Service Request #7454045, if anyone from NI is reading this), is as follows:

I assume that in License Manager during those 30 days you would see a green box next to Standard edition and a half white / half yellow box next to Enterprise. The workaround for what you are describing would be to go into ProgramData (hidden folder, will have to type it into Windows Explorer) >> National Instruments >> License Manager >> Licenses and move the Enterprise .lc file outside the Licenses folder. It probably has "TmpEthernet" in the name. This way, License Manager would not be able to find an evaluation version license and I would expect the checkbox next to Enterprise to appear white after refresh. Then, the software would have to look toward the full license and no builds would be expiring.

This works, but is still leaves the possibility for the step to be forgotten and the software to fail shortly after delivery, which is obviously no good at all!  Please fix this!

It appears that the installer that Installer Builder produces does not check 
that the system has the required components. For example, my app uses .NET 
4.6.1, but the app installed with no warning on a machine that had an earlier 
version of .NET and the app failed with mysterious errors that gave no indication that 
this was the issue. Microsoft's installers could check for prerequisites, 
and Installer Builder has to, too.