build specifications best practice

[ChrisReed]

I am just wondering what other users do when building Installers to find what is the most efficient method.

I used to include the LVRT Engine (LabVIEW Runtime) in the Installer Build

PROS:

1) Only one Installer required for the Target Computer to install everything making it much easier to install.

CONS:

1) Installer is very large - hundreds of Megabytes making it harder to distribute upgrades (eg. through e-mail).

2) Each time you re-build the Installer takes a VERY long time, because it has to include the LVRT.

3) If you change to a different LV version you then have to re-build using the new LVRT and the application EXE.

So I decided to split the installation of the LVRT from the Application EXE.

PROS:

1) The Executable is now very small - say 10 Megabytes even for a large application making it easier to send upgrades.

2) Very quick to build a new Installer.

3) For each version of the LVRT installed, there might be several upgrades to the EXE making this approach more efficient.

CONS:

1) I have to now build & run an Installer for the Apllication EXE AND run the LVRT Installer to install application on Target Computer.

Assuming we use the second approach, what is the best way of building and installing new and/or upgrading EXE applications?

In my application I build a new Executable for each new software change and then create an Installer (with the same version number) to install the new executable as shown below.

However each time I build a new Installer a new Upgrade code is generaterd - {45D6510F-EB72-4DA2-A8E6-A4CB2363129A} in the Version Information window and when I run the new Installer, if there is an existing installation present it just installs over it - BUT when you look in the ADD/REMOVE programs list there is a NEW entry each time a new Installer is run.

Now to overcome this I could just use one common Installer that I upgrade each time with the latest EXE build as follows...

But then I don't have separate Installers for each version and if I want to go back a version I have to build the Installer again.

So what is the best method?

Chris

[PaulG.]

After your first install you should not have to go through a complete install again on that machine. All you have to do is delete the old .exe, .aliases and .ini and replace it with the new ones. Someone correct me if I'm wrong, but I've done this a thousand times.

[crossrulz]

I usually just copy over top of the EXE after the initial install.  Never had any problems unless I had to add something to the ini file between builds.

[Norbert_B]

For longterm support, i suggest you to split the installers apart. One containing all components for executing the application (so drivers, LV RTE), another one for the application and it's support files (ReadMe, config, ...). Let's call the first installer "Framework Installer", the second "Application Installer".

One correction in terminology btw:

Since LV RT is the abbrevation for LabVIEW Real Time, we use LV RTE (LabVIEW RunTime Engine) as abbrevation for the components required to execute compiled LV code.

So why split up?

First, the big Framework Installer is not going to change much. It has to be updated once you update LV or some of the drivers, but for anything else, this could stay the same.

Second, updates for the application can be supplied in small packages. Most developers like to use simple "copy&replace" mechanism to do this, which works fine once you update only a few files; but ojnce you have to update significant things (several files, changes in expected directory structure), i recommend you to use an installer.

Additional note on installers:

Each installer includes something called "upgrade code". This is the key the installer uses to register the application on the system. Once running another installer sharing this key, the OS will treat that as an update of the existing component. This is suggested to use once you want to replace things for a newer version of the application. Manual copy and replacing might induce errors....

just my 5 cents,

Norbert

[ChrisReed]

As the first two posts mentioned I also manually copy the new EXE file over the old one - it isquick and easy, but I only do it for local, single install applications. This particular application is going to be distributed at multiple sites and on many computers.

The problems with the copy/paste method are:

1) As the App builder I know exactly where the application is installed, but my clients don't know where is is installed so I have to tell them exactly what to do and there is more chance of error.

2) If I'm controlling the upgrades then no problems, but it looks "unprofessional" giving clients manual instructions on how to upgrade the application.  It is much easier and less chance of error if I provide them with the new installer and they just run the setup.exe file.

3) I provide the upgrade installers to our IT Dept who will then package them up and do a remote upgrade like when Microsoft automatically updates your computer with the latest patches.  I think they would lynch me if I told them they had to write a script or bat file to manually overwrite the existing EXE file.

So correct me if I'm wrong here, but in the setup in the first image I attached (ie. separately named EXE and Installers), can I copy the upgrade code from one installer to the next so that Windows does not think that these are new installations and create new Add/Remove Program entries each time?

P.S. Duly noted about the difference between LVRT and LVRTE

Chris

[dan_u]

---

@Norbert_B wrote:

For longterm support, i suggest you to split the installers apart. One containing all components for executing the application (so drivers, LV RTE), another one for the application and it's support files (ReadMe, config, ...). Let's call the first installer "Framework Installer", the second "Application Installer".

One correction in terminology btw:

Since LV RT is the abbrevation for LabVIEW Real Time, we use LV RTE (LabVIEW RunTime Engine) as abbrevation for the components required to execute compiled LV code.

So why split up?

First, the big Framework Installer is not going to change much. It has to be updated once you update LV or some of the drivers, but for anything else, this could stay the same.

Second, updates for the application can be supplied in small packages. Most developers like to use simple "copy&replace" mechanism to do this, which works fine once you update only a few files; but ojnce you have to update significant things (several files, changes in expected directory structure), i recommend you to use an installer.

Additional note on installers:

Each installer includes something called "upgrade code". This is the key the installer uses to register the application on the system. Once running another installer sharing this key, the OS will treat that as an update of the existing component. This is suggested to use once you want to replace things for a newer version of the application. Manual copy and replacing might induce errors....

just my 5 cents,

Norbert

---

I also wonder about the upgrade code. Would you use the same code for framework installer and application installer? If so, wouldn't the application installer remove the framework again?

When using different upgrade codes the user will have 2 entries in the control panel > add/remove software. In that case I how would installing a new framework deal with the files modified by another installer (the exe installer)?

Also, will uninstalling both "products" leave a clean system (independent of the uninstallation order)?

[ChrisReed]

No I would definitely keep the Upgrade Codes for the Framework and Application Installers separate.  After all you install them separately and so they should been un-installed separately.

Chris

[Yamaeda]

There's no use to have separate Installer_v2.6 and 2.7 and so on as you have in the first post, when building the installer it'll use the current files anyway ...

Thus:

1 Application

1 Application installer

1 Application and RTE-installer

/Y

[PaulG.]

---

@Norbert_B wrote:

For longterm support, i suggest you to split the installers apart ...

---

Good info and advice here. Nice middle-of-the-road approach. I have never had to rely on a 3rd party to install my upgrades so I've never been that concerned with making errors in the delete-copy method.

[crossrulz]

---

@PaulG. wrote:

---

@Norbert_B wrote:

For longterm support, i suggest you to split the installers apart ...

---

Good info and advice here. Nice middle-of-the-road approach. I have never had to rely on a 3rd party to install my upgrades so I've never been that concerned with making errors in the delete-copy method.

---

I also like this idea because it makes the update installer so much smaller.  You just need to document that the support installer needs to be ran first for the initial install.