LabVIEW
Our software distribution is getting out of hand
Hi fellow forum members,
I need help to get in the right direction regarding how to push our software updates to our customers. Currently we are using this strategy:
1. Create the software and distribute it to the customer using for example a CD or DVD. The DVD contains the setup file and all the drivers needed together with the runtime engine.
2. When we change to software(bug fix etc) we put the updated installer on our FTP server.
3. When our customer starts the software it automatically checks our FTP server for an installer with a higher build than the currently installed.
4. If the software on our FTP is newer, the software automatically downloads the installer to windows temp folder, extract it and installs it.
This works perfectly!
Now over to our current problem:
LabVIEW 2013 is right around the corner and that mean new runtime engine, new drivers etc. We would like to to this automatically so that when our customer opens their software, the software installs the new RTE and the drivers.
What would be the most efficient way to do this?
How do you solve this in your company?
Is LabVIEW able to download and update the RTE from NI webpages?
I think you should reconsider your approach. Upgrading the LabVIEW environment is a serious step. Eventhough the upgrade of an existing application usually happens seamless thanks to a lot of effort by the LabVIEW developers, there are always potential difficulties. So upgrading the development environment for an existing application is always something I only do for major upgrades, never for intermediate bugfixes. And in that case you will probably have to bite the sour apple and require your user to download a new full installer and start it themselves. There are simply to many things that could go wrong during such an install that a seamless installation in the background without user interaction is going to be a viable solution in most cases. \
Also I actually despise software that thinks it should silently install updates without letting me decide if it is an appropriate time to do so. Lets assume you are running a whole series of tests and somewhere in between, when starting up the software one morning it installs a new version silently. Can you absolutely, truely and fully guarantee, that the test results from before and after the upgrade are completely comparable? If you can you are a super programmer! 
But even then that might not be enough for applications in regulated industries!
Thanks for the reply, rolfk,
I forgot to mention that our update service tells the user that there is a new update and that the user can decide if he/she want to update now or later. We never push updates without notifying the customer first and the update usually is based on a bug report from the customer.
I understand what you're saying regarding changing LabVIEW version. The best solution is probably to update our LabVIEW and stresstest the software on the new RTE and then only upgrade the customers RTE if everything is OK. Probably it's not a point to update the RTE before we change the software itself.
i'll think about what you wrote:)
I definitely would install the new LabVIEW alongside I have currently installed about 13 versions of LabVIEW on my machine) and checkout a copy of the source code into a seperate tree to test in the new LabVIEW version. Keep the old version as your main branch in source control. Your new 2013 version should be an experimental branch for the time being and all modifications that are not related to LabVIEW 2013 should be made in the previous version and checked into the main branch. Also I usually wait for the SP1 release of LabVIEW before really switching over for release software.
