4 replies to this topic

[StYerk]

Hi again,

I am authoring the installer for our upcoming release, and this time we want to deliver our Service Packs as Installer packages.

Thus I have to plan my project in a way that this will be possible in future.

Problem 1:
Currently I use merge modules with dynamically linked files including subdirectories. Since these are LOTS of files in a certain hierarchy (that may be subject to change and thus must be included in the patch) this is a real problem.
Changing to static components would mean a huge amount of work for each service pack.
Anyway, since it may happen that the hierarchy changes and thus there will be components missing, this seems to make patching impossible for me...
And I CANNOT (absolutely!) manually put the missing items to delete in the RemoveFile table...
This way authoring patches would take longer than authoring the basic installer...

Problem 2:
Cumulative patches. We will have to provide the possibility of moving from Release, say , 3.2.m to 3.2.N (with 3.2.0 being original release and N the latest patch release, m the locally installed version at the customer's site). For any 0 < m < N.
No clue how to do that.

Problem 3:
I want to have it automated as much as possible. As much as I know now, this is a nice dream...


How can I do this?
- Use InstallShield Patching authoring, having to do all the work by myself?
- Create a completely independent Installer only copying the desired files? Kind of as a seperate product?
- Use a completely different third party tool?

How did other people solve these problems (I do not think these problems are so extraordinary)?

Right now it seems to me, building easy-to-use, correct patches is a matter of heavy development and lots of manual work.

Can anybody help?

Thanks in advance,
Jörg Rohrschneider

[Stefan Krueger]

One solution would be building Major Upgrades instead of Minor Updates, i.e. change the ProductCode. However Major Upgrades usually are shipped as full .msi files, not as .msp patches.

If you want to build .msp patches you should use small or minor updates. This means you cannot remove components, so you shouldn't use dynamic linking for sub folders.

Cumulative patches can be done, but it's easier with MSI 3 because it's "base line cache" so you only need to target the latest minor update when building multiple small updates.

All these are limitations of the Windows Installer technology, not of the authoring tool.

You can use InstallShield's automation interface, or the Windows Installer API (project file in binary format is a MSI database), or XML functionality (when storing the project file in XML format) to automate changes to the project file.

[StYerk]

Hi Stefan

Thank you for your answer.

Using MSI 3 is not possible for now, since my deadline is end of march and we are using DevStudio9 which does not support MSI 3 as far as I know, is that right?
I guess we will upgrade to IS 10.5 and MSI 3 later on, but for now it seems I'll have to stick to MSI2.0.

The other problem is that it is not really good to deliver service pack by sending a full installer of 200 MB.
The changes in one Service Pack usually occur to a limited area of our system,
but one of them is a configuration hierarchy that may change structurally.
As soon as we rename one directory we would have to deliver the complete installer in order to provide a service pack, although this is maybe the only change; this is way too much overhead.

Also, deinstalling and reinstalling, as the major upgrade does, is quite dangerous, since our system has to be customized at the customer's site very much. I would have to author a lot of extra functionality that perserves the customer's configuration areas resp. write it back after deinstall.

I would like to author patches like this:
- For each Service Pack (:= SP), just look at the changes between SP n-1 and SP n
- Build an Installer that updates exactly these files.
- At runtime, check, which SP is installed and install all following SP's

Something like that.
Is there no way I can achieve this?
What if I author these differences as independent installers (like a different product)?
What happens if an installer changes the files of a different product? Or deletes them?

Thanks again for helping,

Regards,
Jörg

[Stefan Krueger]

[StYerk]

Thanks!

This could be a workaround;
I'll try this.

Thanks for helping!

Best Regards,
Jörg