12 replies to this topic

[upwaytoolate]

We've got an (I think...) unusual requirement.

Say a user (it's an internal tool to the company) has version 5.6 on his/her machine. It's discovered that the individual user would be better suited by using 5.5 for whatever reason. Of course, 5.6 was a minor upgrade from 5.5.

Normally, IS would object to the fact that the user was trying to install an older version, and not allow it.

We do know that the workaround is to uninstall 5.6 and install 5.5. As you might expect, the boss doesn't like that prospect. So how can I tell IS to chill, and allow the "downgrade"?

- Jim.

[upwaytoolate]

Gee, it's quiet...

I take it that either this can't be done or that no one wants to touch this one with a ten foot pole.

???

Edited by upwaytoolate, 17 October 2005 - 18:48.

[Glytzhkof]

Short answer: I don't think you can do this in any reasonable, reliable way.

Minor upgrades upgrade the existing product installation and there is no way to uninstall just the minor upgrade changes (unless you are using MSI 3 and installed as a patch - then it might be possible to uninstall the patch).

It MAY be possible to hack things using a new minor upgrade and some creative use of the REINSTALLMODE property, but I would definitely not recommend it.

Safe yourself a lot of trouble and do it the right way: uninstall and reinstall.

[Stefan Krueger]

[Glytzhkof]

If you do need to "sledgehammer this" and force install of the files in the new MSI you can set REINSTALLMODE = amus, but this is most definitely not recommended. It will overwrite all files regardless of version.

[upwaytoolate]

Thanks. Actually that may be what it comes down to.

It's interesting that for an internally used install that the company has a lot of control over, the controls imposed by Windows Installer seem to be backfiring.

This is the second job in a row I've had (contractor) that the boss has requested stuff that is now forbidden, and when advised against and explained why not, has replied that this is getting to be more trouble than it's worth.

The first was a web site deploy that the group wanted to be able to substitute files ad-hoc after install, and of course we had to have a talk about self-repair. We finally succeeded in disabling self repair after a lot of trial and error, but the boss was seriously considering going back to a WinZip install, citing that "Even dll hell was better than this".

[Glytzhkof]

This is exactly the kind of problems we all deal with. What one has to remember is that if you follow the rules and philosophies of a technology they will generally work to your advantage. If you break the rules because you refuse to "...change the way you have always done things" - problems will result.

You are facing people's natural resistance to change. The application of an old installation paradigm to a new one. For MSI to be effectively applied there has to be changes in development, not just release management and setup engineering.

Alternatively you could use a different setup technology during development and only MSI wrap final releases - I'll tell you though: In my experience this will cause even more grief.

[Glytzhkof]

REINSTALLMODE = amus applies to the whole setup as far as I know. As such it could downgrade even system files... (if you have merge modules included).

[upwaytoolate]

Sigh...

After considering the alternatives, here's what management decided.

Have the InstallShield 10.5 package handle the machine prep, (MDAC, DB setup, a few reg settings, etc) and call a custom action that will launch a WinZip self extractable exe to deploy the files. That way they can slide releases back and forth in time for any customer by just shipping them the right self extracting exe, post install. No issues with self-repair or downgrades.

They can do this, because the release is a collection of PowerBuilder pbds, and run-time package dlls which are static.

Okay. We *are* hired to advise, and then to carry out their wishes in the best manner possible, and the check does still cash. But I must say, I still feel quite ill.

InstallShield and Microsoft both, please take note; many software departments and their managers have no interest whatsoever in Microsoft's Best Practices. They simply wish to get their product out. Period. They consider that limits such as hurdles to downgrades, and indeed self-repair itself are considered hinderences and obstacles to getting the job done.

Think I'll go for a walk, now. Maybe chocolate... hmmmm........

[Glytzhkof]

As I am sure you know very well, you'd be better off using a real Installscript project (not MSI) for this.

[upwaytoolate]

Well, it's funny you should say that, because I had been daydreaming "if only...", but I also remembered about a year ago when an InstallShield Tech told me that even the Installscript projects were MSI based underneath nowadays, which would mean that self-repair would still be an issue.

Am I recalling wrong?

[Glytzhkof]

There are Installscript MSI projects, but there are also pure Installscript projects. In the latter the whole installation is run as a script, and it has nothing to do with MSI as far as I know.

[Stefan Krueger]