Patching Installshield 2010 projects

[majorextrasize]

Hi all,
I am new to Installshield so please be gentle.
Our company has a product packaged in Installshield 2010 and now we need to devise an update/upgrade strategy.
Our main install has a version number of 1.00.0000
We need to apply a series of silent patches sequentially to the product, namely 1.01.0000, 1.02.0000, 1.03.0000, 1.04.0000, 1.05.0000 etc. Each patch depends on the previous patch being already installed. In each patch we need to update dlls, registry and run an Installscript custom action.
We also need to release a Service pack that incorporates all of the changes of 1.01.0000, 1.02.0000, 1.03.0000, 1.004.0000, 1.05.0000 in one package. This Service pack package also has to be silently installable regardless of what patch or patches are already installed by the customer for our original product.
Is this possible using Installshield 2010, and what do I need to do?

[mumbles]

Well i'm going to make some assumptions. Firstly,you are using a Basic MSI (Which can contain installscript actions).

1. Your main package will be 1.0.0, thisis a basic MSI and will provide the 'base' install.

2. To run installscript and other actions during 'Minor Upgrades' these will also be the same basic MSI's, but the minor version will be updated. (1.1.0)

3. You can create patches to patch a file, or a registry key, those are .MSP files. This are very simple and small in size, typicallly. (1.1.1) but those cannot contain everything from previous releases, as they are limited in functionality. So essentially you are looking at having Major Versions and then performing a series of Minor Upgrades as all your upgrades AND service packs. Installshield doesn't really have the concept of 'Service Packs' like microsoft does. They are just ugprades (msi files) or patches (msp files)

4. I personally suggest using the fourth digit as a build number (1.0.0.0). Installshield ignores the fourth number on Major and Minor upgrades and once you get into the full swing of things, the fourth digit will be good to know exactly which build someone has on their machine. But that is just my preference, not mandatory.

5. You don't specify if things run silently in the installer itself. THe way you run the installer, from a batch file, from command line, etc... determines if it is silent.

For example; msiexec 'mymsi.msi' /qn will run any MSI silently and ignore any prompts or input needed. Sometims this is good, sometimes it's bad. UAC on vista and win7 it can be bad if you need to perform any administrative actions. Because running it silently will mean the adiministrative action is ignored.

In terms of how upgrades work, while in installshield;

1. Go to the top 'Installation Designer tab'
2. Expand the 'media' folder
3. Double-Click on upgrades.
4. Additional Information

This area should tell you everything you need to know about upgrading.

[majorextrasize]

Thanks a lot for that Mumbles.
I have actually read the document 'Minor and Major upgrades' but one thing which it doesn't make clear is sequencing.
For example can a minor upgrade patch act as a Service pack, ie incorporate all of the changes of the sequence of sequential updates?.
ie can two minor update packages(1.01.0000 and ServicePack1) reference the same original package and be expected to work?


1.00.0000 -> 1.01.0000 -> 1.02.0000 -> 1.03.0000 -> ServicePack1
|
V
L -> 1.01.0000 -> 1.02.0000 -> ServicePack1
|
V
L -> 1.01.0000 -> -> ServicePack1
|
V
L-> ServicePack1

[mumbles]

Minor and Major upgrades differ greatly in that, a major upgrade works the way you expect. It first goes in and removes all existing features (Files, registry keys, other settings) and then puts new ones in.

Sometimes, you may wish just to upgrade some files and such. If you want to just keep adding onto what you had in previous releases, you may wish to just stick with Major upgrade.

That is what we do. We only perform major upgrades. If package size is not a huge concern, (Like downloading MSI's from the interenet) this is often the best way to go, in our experience...

Minor upgrades and patches are good for patching files, having some logic t modify values etc... but are not considered additive.

What we do is,

1. We create our Basic MSI.
2. During every release, we modify our product code. But leave our upgrade code alone (Very important step)
3. We match the assembly version of all of our DLL's
3. Update the product version, doesn't matter if it's 4.1.0 or 4.1.1 we do a major upgrade regardless.
4. deploy.

This way, since size is not a factor for us, we don't need to determine the changes we make. We simply push out a whole package every time. While this may not be optimal to some folks for various reasons, it's worked fantastically for us.

.02

[mumbles]

majorextrasize wrote:



1.00.0000 -> 1.01.0000 -> 1.02.0000 -> 1.03.0000 -> ServicePack1
|
V
L -> 1.01.0000 -> 1.02.0000 -> ServicePack1
|
V
L -> 1.01.0000 -> -> ServicePack1
|
V
L-> ServicePack1

Major upgrades could work for ALL of this scenario.

[majorextrasize]

Thanks for that mumbles.
I think a small update for the sequential updates and a minor upgrade for the cumulative service pack will do the trick. Although I have to test it.
Ill let you know how I get on. Cheers for the help.,


Edit:19/01/2009
Yes this was in fact what I was looking for. The fact that the product number didn't change meant I didn't get the Upgrading from wrong version message box.
Cool.