12 replies to this topic

[StYerk]

Hi again,

still stumbling on with that patching horror...

My current problem:

I have finally managed to create an patch/upgrade for our software
(using DevStudio9). Now I ran into the following problem:

When I package my 'ServicePack' (which is a major upgrade) into an 'Update.exe', nothing gets installed. There's no error, simply nothing is updated.
I have noticed that when I pass parameters to Update.exe via /v
(like /v"/l*v c:\Temp\bla.lo"), everything works out just fine.

After a LOT of investigation I finally found out that this results from the fact that Update.exe by default sets 'REINSTALL=ALL' when calling the contained patch installer and thus the Property 'Preselected' is set to 1 which prevents the action 'MigrateFeatureStates' from working. If a parameter is passed, this behaviour seems to be suppressed and only the given parameters are passed on, so 'Preselected' is only true, when REINSTALL, ADDLOCAL, etc. are explicitly set in this parameter(see MSI help on 'Preselected property').

So far this is not THAT new, I know, but how can I work around this? I haven't found a solution, is there any?
Resetting 'REINSTALL' by custom action has the result that EVERYTHING gets installed, but I only want to update those features that are already installed.

The only way I have seen is to not create an 'Update.exe' and just create the *.msp patch.
But that is not really good, since I have to call some Installscript action, that means I must add the Installscript-Engine Installer. But I just want to have a single, simple executable that I can deliver to our customers, he starts it, update runs and that's it.

Is there any way to reset the 'Preselected' property? I know it's private but is there really no way? Or can I work around this any other way?

Thanks for any help,
Regards, Jörg

[gstock]

Are you updating the package code when you are creating your upgrade? Your product code should stay the same, but if your creating an upgrade, your package code should change.

If you don't do that, you need to look at the ReinstallModeText propoerty, and look at setting it to vomus instead of omus. This is not really recommended though.

[StYerk]

Package code AND Product code is changed;
I have to change the product code, since it is a major upgrade.

This behaviour only shows in a major upgrade by patch.

[StYerk]

[Stefan Krueger]

The "v" is only required for small or minor updates using a full msi file. It's not necessary when installing a patch (.msp) or when installing a major upgrade.

Did you try the "MSI Command Line Arguments" setting on the Advanced tab of your patch configuration?

[StYerk]

I only set it explicitly to 'vomus' when IS_MAJOR_UPGRADE is defined, i.e. in a major upgrade.

The value of ReinstallModeText is also 'vomus', but this only is used in a real 'Reinstall', if I remember it right...

However, in DevStudio9, which I am using, there is no such entry "MSI Command Line Arguments" in the patch configuration, in none of the nodes...

[StYerk]

Ooops, correction:
I set Reinstallmode to 'vomus', when IS_MINOR_UPGRADE is defined, i.e. in a minor upgrade!

Sorry for the confusion.

Anyway,
anyone has further ideas to solve the above problem?

[Stefan Krueger]

[StYerk]

Do you know something else I can do?

[Stefan Krueger]

Don't ship major upgrades as patches, but as full msi files (this is a recommendation from Microsoft).
Or don't use update.exe.
Or unset the REINSTALL property using a custom action early in your sequence.

[StYerk]

Resetting REINSTALL is not a solution, because this installs EVERYTHING. But I only want to update the features installed on the customer's site. And there seems to be no way to find out what is installed in a Basic MSI project. That's what the MigrateFeatureStates action is for. But that does not work properly, if 'Preselected' is
set.

Also, I cannot ship this upgrade as a full MSI and other ones as patches.
Our customers have different versions of our software and I cannot expect of them to perform multiple steps to update to the current version.

The situation is as follows:
I am creating Service Pack 2 of our software (version 3.2.2).
Original release was 3.2.0. The first Service pack has not yet been shipped as an installer/patch, but the step from 3.2.0 to 3.2.1 conatins changes that force this patch to be a major upgrade. The step from 3.2.1 to 3.2.2 is a minor upgrade.

So, if I use different patch types for each version step, what a customer who has our 3.2.0 would have to do is
- download 300 MB installer of 3.2.1 and update to 3.2.1
- perform a lot of checking and adapting of customizations
- then download the 3.2.2 patch
- and again do the whole adaptations.

This is not acceptable.

I see it so often in other software, that I simply download a small executable; this detects the version I am currently using, updates what is necessary, and then I have the new version. No big installers, no different steps.

Was it the wrong design decision to try to use the recommended standards (MSI)?
As far as I can see now, all MSI does is PREVENT me from easily upgrading and delivering software.

I am trying to write patch updates for three months now... And it looks like IT IS NOT POSSIBLE. Although I have a software designed for this, costing as much as a car.
The relationship between effort and benefit is more than bad.

Sorry, but I had to write that off my soul.

Anyway, the way it is now, I cannot use the whole stuff. If anybody has ANY hints for me, including using other technologies or workarounds or anything, I would be very happy.

Thanks for helping,

Regards, Jörg

[mpento]

I have to admit, I feel your pain.

I have worked with InstallShield for many years in many different capacites. I have found it to be both a god-send and a nightmere depending on the circumstances. Lately, it has been more the latter than the former.

I am currently in the throws of upgrading a package that was developed before I got my present job and I am having the same basic issues as you are. All I want is to distribute the MSI and have the thing replace the files that are changed, but, there seems to be no easy way to do this.

It's trbouling since I see other software companies using either other products such as Wise Installer or creating custom packages for installing patches and upgrades that work great, yet, the "industry leaders" can't seem to do this right.

Essentially, the impression that I have gotten is that there are too many options for creating an upgrade, and too many little nuances to worry about; when do I change my product code? When do I change my package code? What does the upgrade code really mean? What switch combination should I use with the "ReinstallMode" property? Major upgrade is too much but minor upgrade is not enough.

Hopefully, these issues will be addressed in future versions of IS, sorry for the long rant,

Mike

[Stefan Krueger]