LabVIEW
Application builder problems, help wanted
Maik S. wrote:Hello!
We are using LabView 8.5. Since LabView 7, the application builder has changed very much, bringing serious problems (see below). I would like to know a way to avoid these problems, since an installer is required to bring our software to our customers.
1. The builder automatically includes 19 or more packages not necessary for our software to run
2. The builder blows a small program of <1MB up to about 80-100MB
3. The installer installs 7 unwanted and unnecessary services
How can I avoid the builder to create such huge installers (the reason is not HDD space) and prevent the installer from installing the services?
Windows services are one of most nastiest things. They often run, use resources and slow down the PC without any sense. In LabView 7 they were not created by the installer and the software worked fine. Even for smallest application, where only a small VISA package would be required for hardware interface access (RS232, USB), the builder creates 80MB installers.
In order to create a custom installer with InstallShield or similiar, is it possible to implement VISA package installers and run them during the software installation? This is in order to circumvent the still existing limitations of the application builder (I don't know for sure, but I think it still can't install fonts).
Well, the same could be said about Windows. a bare bone installation used to be maybe 100 MB. Nowadays you do not get it below 3 to 4 G even for XP and a lot more if you keep it up to date andallow the System Update to install all recommended stuff (.Net 1, 2 , 3, 3.5, etc anyone). So should we complain? Maybe! Will it change anything? No!
Vista got bigger again and I'm sure Windows 7 will not really be smaller.
The same happens with LabVIEW. It evolves, adds new things and the runtime engine alone is in 8.6 already around 160MB. Yes you do not need everything for every application and there are other dependencies that get installed with the runtime engine too, though most of them are not very big. The Create Installer section in LabVIEW could be made a lot more detailed, so you can check all the subparts that the runtime engine consists off and also control its dependencies, but such a configuration would be VERY, VERY involved to do and that would require a lot of extra effort from the developers for the Create Installer Tool and also add a lot of extra effort to any new release of the runtime engine and all the driver packages.
And last but not least nobody, not even you, would know what all needs to be included in such a complicated installer build configuration to make your application work on any possible computer. There are differences that depend on the target machine too. So first you would do about two dozen installer builds incrementally adding extra sub sets and install each of them on a few fresh computer to see if it will work. Don't try to test incrementally on your development computer as you would not even need to install anything but the files copied to your build directory since it has already everything installed. Even testing on a non clean machine could show you a working application that will fail grandiosly on a customer computer, preferably when he is at the other side of the globe and has no internet access to download the drivers and runtime engine from ni.com.
So yes NI could invest many man years of developer time to give you a very fine grained possibility to configure what is to be included in the installer build, but you would most likely not use that possibility since it would be very cumbersome to understand and use and you would have to do many installation tests for each new build to make sure that you have exactly selected the right components to be installed on a fresh computer. It is just so much easier to click the few global modules and specify to include everything in there.
Rolf Kalbermatter
Maik S. wrote:
LabView is not an operating system. Waste of space and resources done by other companies is no reference for NI to do the same.
Bad enough that it needs a runtime engine, instead of including all the code in the built application, like when building an C++ application for Windows. But this seems to be a problem of software developers today, to rather create a runtime that is required for a software, than to make a neat and small all-in-one package.
You should investigate before making claims. Even a bare Visual C++ application needs at least the redistributable C runtime libraries included in order to make sure that someone can run it on an older OS than the one which was build using that Visual C release.
Start to use C# and you are even much more further from having a single executable that contains everything to run on any not to old Windows system.
