LabVIEW run time engine included in application exe

[Martin.D]

Hi all,

Back in LabVIEW 5 we could create a single LabVIEW application exe file that included the runtime engine (all in one exe file). Now we have to install the runtime engine in its own right + the LabVIEW application exe. I don't suppose anyone knows any way to create LabVIEW application exe files that include the runtime engine in new versions of LabVIEW.

I know we can install the runtime automatically while installing the LabVIEW application.

I also know it does make more sense to have the runtime separate from the application for updates etc. but in some situations its nice to just have one program visibly installed on the system - the application of interest.

Any neat soloutions known?

- Martin

[Akiel]

would be a good idea to put back in, i couldnt see the option in 2010. I believe its still in in teststand not that thats much help to you

[Martin.D]

Hi Akiel,

I'm glad I'm not the only one who would like the option back.

 -Martin

[blawson]

I do one of two things.

1) create an installer with the additionals you want.  duplicate it, and uncheck the additionals.  This is the "patch" installer.  You'll want to copy the UpgradeCode from the first build spec to the other one, so the patch doesn't install as a second program in the windows add/remove programs dialog.  Main drawback is that any changes to the build spec have to be made in two places.  LV is abominably slow opening build specs even on my quad core machine with an SSD hard disk, so this is not an insignificant annoyance.

2) create an exe-only installer, get NI installers for the components you need, and script the installs together with NSIS.  There is much more flexibility with NSIS, but you have to learn to use it, and NI doesn't always release standalone installers at the same time as what's included in the dev suite.  Sometimes I have versions of drivers or runtimes that I installed with the full version of LV but I can't get a standalone installer of the same version.  I have a few NSIS installers that include features like checking for .NET frameworks, giving the user more install options, conditionally installing NI components, etc.

I choose 2 when I need lots of control, I choose 1 when an NI installer can handle everything.  It would be nice if NI made it simpler.

[Akiel]

personally i use inno setup. works like a dream if i need to instal multiple files, run other setup programs etc....

[Martin.D]

Thanks Blawson,

Not sure this will achive exactley what Im after (unless I misunderstand) as I think I will still need to install the runtime engine on the system as a seperate program at some stage and it will appear in the add/remove programs etc. May be I can just copy the runtime dll file to the target system and do a bit of programatic registery editting. But I imagine I could end up wasting much time experimenting with that and it could be fruitless. And even then its not as good as it all being encapsulated in the application exe file like it used to be in LabVIEW 5. Guess I'll just go with the standard multiple installs for now.

[rolfk · Accepted solution]

The days of one file applications are long gone. The current LabVIEW runtime engine is a large combination of many files including DLLs, UI model files etc. Not everything of that is always necessary but even the most trivial LabVIEW application nowadays takes several dozen of these files to even startup. It's how things evolved and while there are indeed some efforts to get applications to allow to run from a single location in order to put them for instance on an USB stick, LabVIEW is not really a system that lends itself for that. In LabVIEW 7.1 and 8.0 you could basically include all the files that make up the runtime system into the same folder as your executable, and no NI never supported that nor will they likely go to do that. With some trial and error you could start removing files and see if your application was still working afterwards, but it was a tricky procedure since the application could often startup fine, but suddenly run into display problems if you opened a subscreen or something with particular objects on it.

You can probably try by simply copying all the files from the LabVIEW Runtime folder into your executable folder and there is a chance that this still works, but for what? The installer size stays basically the same and if you happen to install two applications on the same computer, each contains a copy of the entire runtime system, so there is not any gain anymore but in fact a setback.

The interdependencies of those modules are complicated and some need additional components and registry settings to properly work. Also providing a way to configure individually what you want to include and what not would be a total pita for the end user as nobody would really understand what is needed for what and why. So the experience would be mostly try it once, doesn't work and never use it again.

I never have bothered to look into this for newer LabVIEW versions. The time needed to figure all out is simply way to much to bother for the little gain you get. Installers are the standard nowadays.

Another issue that would come up then is that you need to monitor all NI security advisory reports and other bug fixes and act on them yourself whenever a component that you have added into your application needs updating. As it is now, the NI Updater can and will update the according centrally installed runtime system and all is well.

[blawson]

Ah, I misunderstood what you were looking for.  Rolf is correct, there's no way to roll the runtime into your application anymore.  You can make a single installer that includes it.

The situation is much like microsoft .NET.  If you have a .net app or components, you need the framework (and the correct version!) installed on the target before it can run.  The target computer's administrator is free to uninstall the framework and then find out it doesn't work.  I'm also free to take the wheels off my car, and then it won't work.

What I'm describing is a way to distribute two different versions of an installer: one which installs all dependencies (runtime engine, daqmx, etc.), another which only updates my application.  Often the former is HUGE.  I might have a gigabyte sized full installer, but then the app-only patch installer is 10 megabytes.  It's faster and more manageable to work with the 10 mb file where possible.

[Martin.D]

When isn't Rolf correct?

Looking back I could have been more clear in my previous posts. Thank you for your input anyway Barret you outlined a good approach for distributing patches.