A scathing review based on my experience upgrading from labview 7.1 to 8.2.

[billings11]

Travis,

Yes that thread is exactly the problem.  But you have to understand the implications of that posted solution.  I've written dozens of little applications and big applications in labview at my company over the last few years.   There are dozens of little executables being used all over.  Some are just slick GUI's to look stuff up in databases, and some are huge multi-threaded burn-in test racks.  So over about 50 or 60 comuters we need to maintain about three dozen labview applications written in different versions of labview.  Again some of these are very simple apps, but they still have to be maintained because people need them.

This bug effectively means any application I built in 7.1 needs to be regenerated in 7.1.1 or later if we are going to keep using it.  You can't install a 7.1 runtime engine without breaking the 7.1.1 runtime engine.  I am going to say here that that type of problem is an unacceptable issue that is just as bad as broken code.  It should have been tested for and found by NI long before the 7.1.1 release.  The solution to that thread is fine if you are only worried about two computers.  But when you have to maintain these applications across 60 computers this suggested solution is a huge inconvenience.  And I believe 36 of those computers need DAQmx.

So we have to not just install, but maintain these PC's.  Hard drives crash, new computers are bought, new installations have to be made for new programs I write, etc.  So say someone would like to install one of my labview executables.  The IT guy who does the installation has to know what labview version this application was written in and what labview version any other application on that PC is as well.  If it was written in 7.1 he will need to first check to see if there is a 7.1.1 runtime on the PC, uninstall it, then install the 7.1 runtime, then reinstall the 7.1.1 runtime.  Or if the PC is already carrying a 7.1 runtime and the new application tries to install a new 7.1 runtime it will simply uninstall the old one and you will be left with no runtime engine. 

I also need to use DAQmx 7.5 or later.  7.4 and eariler had a bug that I posted about at the time, where the property to tell you the current sample index in the output buffer would reset to zero as soon as you stopped a DAQmx task.  If you stopped a task you couldn't tell what index in the buffer you stopped at (it always returned zero), so you had no idea what voltage you stoppped at and you couldn't build a ramp back to zero.  Anyway it was fixed in DAQmx 7.5, so I have to use at least that version, which means a 7.1.1 runtime on 36 computers even though they all carry labview executables from 7.1.  You can see that for an IT department, maintaining these installations quickly turns into a big look-up table of how to carefully install each application without breaking another installation.

So this is my point, that a simple installer bug can turn into a massive headache, and it can cost just as much time as broken code.  Once you compile an exe sometimes you'd like to wash your hands of it.  But now I need to go back and rebuild 30 something executables in 7.1.1 or 8.2 just because of the 7.1 installer bug.

[Andrew W]

Hello Billings11 -

Thank you for your posts and detailed feedback.  I would like to address some of the MSI concerns that you had brought up a few posts back in the thread.

You are correct in pointing out that NI's MSIs do not function as normal MSIs.  We made the decision to create functionality which would extend MSI and allow us to create more robust installers.  Our current installer framework acts as a supervisor over the installation.  It has the ability to mark and match dependencies (more functionality than the MSI reference count) which are important when other NI products are being installed or if any product is uninstalled.  The installer framework also provides a lookup service to all of the MSIs which can provide any installer with specific information about other NI products installed on the machine, paths to those products, etc.  The framework gives the ability for groups within NI to create separate installation parts (MSIs) which can be brought together into one installer without recreating a single distribution MSI from scratch.

Extending functionality outside of normal MSIs also means that installation via a network group policy is no longer supported. 

To support deploying through Active Directory, we would need to remove our installer framework instead and ship each piece of software as a single MSI.  The features our framework provides would be eliminated, and much of the burden of tracking dependencies would be pushed onto the customer.  Installation procedures would most likely become more complex, as each MSI would also be relatively blind to the current set of NI products on the machine.

To distribute the NI installers to many machines, our recommendation would be to place the installer on the network, use Active Directory to define the policy, and then distribute the software through Microsoft SMS (or a similar tool) by running the installer in silent mode.  This involves creating a spec file, and then running 1 or more installers silently as part of a batch file.  You had already brought up this point in a previous post:

"You might suggest running batch files as login scripts.  But it takes longer for someone to create and test a batch file silent install than new installation in a real MSI file.  You have to look up all the right switches to run the installation in silent mode with the right options - its a pain.  Its really better in the long run to take the time to recreate NI's installation from scratch so you can have a real windows installer from that point forward."

I completely agree that the process for creating a batch file for the silent installation of NI products should be improved.  We are working hard to create a process in which you can 1) create a spec file simply and quickly and 2) be able to run the installer easily in silent or basic mode.  These improved features should reduce the issues your IT would have with NI software distribution through Microsoft SMS (or equivalent product).

Thanks again for your comments and have a great day!

Andrew W

Software R&D

National Instruments

[billings11]

Andrew,

I think you have made a mistake in your reasoning and decision making when it comes to installers.

1. We made the decision to create functionality which would extend MSI and allow us to create more robust installers
1. It has the ability to mark and match dependencies
2. MSIs which can provide any installer with specific information about other NI products installed on the machine, paths to those products, etc

Windows installer and other installers also have this ability as well.  For example, when we install the latest Visual Studio or other applications it checks to see if the Dot Net framework is installed.  Even something like our United Parcels Service software checks for other dependencies like an Access Runtime engine, MDAC, and other supporting components.  One of the more difficult problems we have with the NI installer is that it does not gather the correct information for the installed products for an easier install.  The MS Office Report toolkit is a good example because it does not install it in the proper directory when we upgraded from 7.1 to 8.2.

Also, sometimes the installers install extra components.  In the NIDaq version 7.5 it auto installs LV 7.1.1 Runtime which ends up causing us problems when we add a second or third 7.1 app later.  We never know what we are actually installing along with what we think we are installing.

2. Extending functionality outside of normal MSIs also means that installation via a network group policy is no longer supported.
   
   If group policies were still supported it would be bit of work to create the installs, but far less work than it is now.  Now our options are to create silent installs for each version of LV and each individual tool kit.  Some of these need the custom spec files edited and the options in these are extremely cryptic.  I can guess at what each line is, but I see bunches of options that I would like to skip or add and have no way of knowing how to add or remove these options.
3. To support deploying through Active Directory, we would need to remove our installer framework instead and ship each piece of software as a single MSI
   
   I am not sure if I completely get this, but each application like the toolkits are their own install anyway.  The lastest toolkit CD “looks” like you can select all the toolkits you want in one shot, but they still require babysitting because every single one asks you for various pieces of information.  Basically I am only saved a few clicks by not having to go to each folder on the CD to click the Setup file.
4. The features our framework provides would be eliminated, and much of the burden of tracking dependencies would be pushed onto the customer

 Unfortunately, this is the very state we are in now.  A one time install may go well, however upgrades can be very difficult.  Not being able to adequately deploy the solutions takes a lot more time.  For example we created a scratch install of a computer that needed LV 7.1 and 8.2.  From start to finish just for the LV installs, support files, and correcting the problems where the toolkits did not install properly in the 8.2 folder took about 5 hours+ for just the LV.  And we have been working for over a month now to figure out how to get all the silent installs right to deploy runtimes, daqmx, etc to numerous PC's.  We still haven't upgraded the majority of our computers with the 8.2 set of distributable software.  To us, the features of your framework are the source of our problems and do not assist in any observable way.

[billings11]

5. Installation procedures would most likely become more complex, as each MSI would also be relatively blind to the current set of NI products on the machine

That is OK.  Group policies allow you to install in an order within that policy.  All we would need to do is know what the prereqs are just like any other package.  You have taken the stance of trying to dumb-down the installer so you don't need to know what any dependencies are for things to work.  But you have really cost us an inexcusable amount of functionality.

6. Distribute the software through Microsoft SMS (or a similar tool) by running the installer in silent mode.

That is a lot of money.  We are already paying $4500 per labview license.  We shouldn't have to buy more expensive software to do something any properly made installer should do automatically.

7. Create a spec file

As I pointed out earlier, this is almost impossible to get all the apps installed because the spec options are limited and from what I can see, undocumented.

8. We are working hard to create a process in which you can 1) create a spec file simply and quickly and 2) be able to run the installer easily in silent or basic mode

When will they be done with this?  We're certainly not upgrading ever again to any version of NI software that doesn't have this in an implementation consistent with what a modern installer should be in 2007.

[billings11]

tst said about getting around local variables:

A common method for the issue you brought up is creating a cluster and passing that cluster through the shift register. Whenever you need a variable (a cluster element) you bundle and unbundle as needed.

Yeah I can see what you mean tst, that sounds like the best option if you don't need that data as part of a GUI.  But what if you have waveform graphs on a front panel, or something like that?.  You can't bundle them because you can't get to the specific control properties if its bundled.  Usually I will be programatically setting graph scales and colors and stuff like that.  So if you wrote a "virtual oscilloscope" type application you would have to pass almost all of that GUI data in separate shift registers.  It would just be awesome to get something like a local variable that points to the original control's memory instead of copying it.  I bet if they made it a priority they could come up with a cool a way to implement that while still staying true to dataflow.

Message Edited by billings11 on 06-22-2007 08:38 AM

[Ben]

" I bet if they made it a priority they could come up with a cool a way to implement that while still staying true to dataflow."

Great idea!

I wonder how long it would take to introduce such a concept?

Ben

Message Edited by Ben on 06-22-2007 08:44 AM

[tst]

---

@billings11 wrote:

You can't bundle them because you can't get to the specific control properties if its bundled.

---

Sure you can. Have a look here for an example which even shows delegating the code to a subVI (open Demo.vi). 

[tst]

And just to explain it in words - essentially, you add a reference to the control to your SR and initialize it to point to the actual control at startup.

[billings11]

tst,

Yeah I was sort of playing with that after my post last week.  I knew you could get to the array of references, but I never tried teh To More Specific Class functions.  You can pretty much still get to everything.

Message Edited by billings11 on 06-25-2007 05:52 AM

[billings11]

So we have been working for a coupe of days now continuously trying to get a silent install going for labview 8.2 and all the other pieces of NI software to go on a development PC.  Here are our issues so far:

While trying to use the methods they describe for installing LV and support files we run into the following issues:

Installers seem to be made with at least 3 different installer like InstallSheild, Wise, and others.  This makes things difficult because we have to use different command line switches for the apps. 

1. The LV SPC toolkit seemed to have some sort of path limitation.  We copied the Toolkit CD to the network share using the same folder structure on the CD and setup will not run.  If you move the install folders up higher to the root, they run.
2. The CVI SPC toolkit cannot be installed silently.
3. All the toolkits that had a setup.exe and some MSI file in the folder would not run by using the setup.exe and the switches that the command setup /h would list as suggested by NI.  You had to run it by the MSI file name then the switches.  Setup did not pass the switches.
4. Some of the default spec files templates did not work when called in the command lines.  They had lines that the setup did not recognize:
   • Advanced Signal Processing did not recognize the only key in the file “NIDIR=C:\Program Files\National Instruments”.  Error was Bad Key
   • Signal Express did not like the line “SignalExpress.MSW111APP001=Default” in the [Features] section.  This is the only feature line in the file.  Also a Bad Key error.

Attached is the install batch file I had to create to try to silently install as much LV 8.2 as possible.  This is just for clean installs without previous versions.  You can see:

• All the different command lines
• All the different switches from command line to command line
• All the different spec files that need to be edited.
• How some of the tool kits do not install silently.