Always act as a major upgrade

[Kelter]

In short:

Is there a way to make the installer always behave as a major upgrade without having to change the product code? More precisely, every time the installation runs, it should remove the current version of itself. This should work for downgrading as well (if we inject a dysfunction, we want to be able to restore the previous version).

The long story:

We have a Basic MSI project. It uses Dynamic File Linking, so minor updates will not work. Also, I'm installing web applications, and if the application already exists, we need to remove it, because ISIISInstall totally ignores the differences in IIS configuration if the app already exists.

Failed Attempts:
I've attempted a few different ways to do this, but it seems like none of them will work.

1. I tried to set a Major Upgrade Item for versions between 00.00.0000 and 255.255.65535 inclusively, but the installation is launched as a minor upgrade before the MSI stuff even runs so it will run in maintenance more and FindRelatedProducts will be skipped.

2. I removed all upgrade entries. I tried scheduled a custom action that would call msiexec.exe /x[ProductCode], but by this time, the costing operations have already run and "REINSTALL=ALL".

Has anyone wrestled with this problem and found a way around it? This seems like a common-enough scenario (requiring full uninstall during every upgrade).

[klacounte]

Why do you not want to change the product code for each release? If you had a custom bootstrapper, you could generate a transform that changes the product code but I think that would cause problems if you needed to release a patch. It'd be better to manually change it before building or use the automation interface to change it.

BTW If you configure the Previous Package property on the release settings, it will match up the files included from dynamic file linking. That should resolve the problem you saw with minor upgrades.

Downgrading is a different story. See this post and MichaelU's responses: http://community.flexerasoftware.com/showthread.php?192165-Downgrade-or-rollback-to-previous-version&highlight=downgrade

[Kelter]

Thank you for your reply.

Because I don't want to have to modify anything between releases. We have a buttload of web apps with their own installers. We want to be able to take any package built on our build server, run it through QA, and then deploy it to the web server. It doesn't make sense for me to have an extra job to do to bump that value on every build. Also, I don't want to have to think about what copy of the current package is currently installed on the production machine. Chances are, the official QA silo will be getting wiped for each QA build, but the development silo used by the developers will probably have a fairly recent version currently installed, and the production environment would have a less recent copy installed. It's a mess to try to accommodate for all possibilities.

Also, let's say a release includes a change to IIS settings for that web app. If you don't delete and then re-create the web app, then the settings never change. I consider this to be a bug in ISIISInstall. If it finds that the app already exists, then it makes no configuration changes.

So there you have it, I want every install to work as a major upgrade and I want everything automated so that no manual work is required to change the installation project between builds. This would ensure that every installation will create the desired system state regardless of what, if any, version of the product is previously installed.

[klacounte]

So would using the automation interface to build the install work for you? It'd be fairly simple to change the product code automatically if you can use it.

Kelter wrote:

Also, let's say a release includes a change to IIS settings for that web app. If you don't delete and then re-create the web app, then the settings never change. I consider this to be a bug in ISIISInstall. If it finds that the app already exists, then it makes no configuration changes.

I'm not sure that it's a bug, more like a deficiency. Sometimes people want to use the IIS settings as defaults and the end user is free to modify them, this is how ISIISInstall behaves. In this use case running a repair on the install will retain the end users modified settings. The other use case, which is the one you're talking about, is that the install should have full control over the settings and running a repair should reset any modifications made by the end-user.

We had the same problem as you but also wanted to preserve user modifications to some settings. We solved the problem by writing custom actions to save off all of the IIS settings, delete all of our applications and app pools, and then restore specific settings which may have been altered by end users after ISIISInstall has completed. I can give you more specifics if you're interested.

[Kelter]

I can see reasons for both use cases, but perhaps that should be a feature request. Add a checkbox to optionally overwrite IIS settings. I consider it a bug because the intent of deployment automation is to put any machine in the exact same state after running the deployment. If I set registry entries in the package, and the user changes them, and stuff breaks, the user should be able to run a repair and restore the values that are guaranteed to work. Why should IIS settings be any different than any other configuration item?

I think for integration into TFS build, the easiest way for me to implement this is to write a C# custom build task that will simply swap in new GUIDs during the build via a RegEx. I was just hoping for some intentional support for this scenario as it seems like it would be common.

[Sangeetatomar]

I'm facing the same issue. Doing a major upgrade but ISIISInstall is not creating the site. Could you please provide more details for the solution.

klacounte wrote:
So would using the automation interface to build the install work for you? It'd be fairly simple to change the product code automatically if you can use it.



I'm not sure that it's a bug, more like a deficiency. Sometimes people want to use the IIS settings as defaults and the end user is free to modify them, this is how ISIISInstall behaves. In this use case running a repair on the install will retain the end users modified settings. The other use case, which is the one you're talking about, is that the install should have full control over the settings and running a repair should reset any modifications made by the end-user.

We had the same problem as you but also wanted to preserve user modifications to some settings. We solved the problem by writing custom actions to save off all of the IIS settings, delete all of our applications and app pools, and then restore specific settings which may have been altered by end users after ISIISInstall has completed. I can give you more specifics if you're interested.

[klacounte]

If your applications and app pools exist and you want them to be re-created, then you should write a custom action to delete them before they are created by the InstallShield custom action.
If they don't exist and they're not being created, then the InstallShield custom actions probably aren't being executed. Check the install log to figure out why.