4
votes

I am facing a problem for several days and after many research I couldn't find anything that fit with my case.

Here's the thing : I'm working with Visual Studio 2010 on a solution that contains several projects and a Setup Project. I want the setup project to create a MSI file to update the product from version 1.5 to version 1.6.

I followed this tutorial http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/ and updated also the assembly version and file version numbers of each project of the solution.

The settings of my Setup Project are :
DetectNewerInstalledVersion : True
InstallAllUsers : True
RemovePreviousVersions : True
Version : 1.6.3
The ProductCode is different from the ProductCode of the previous version
and UpgradeCode is the same than the UpgradeCode of the previous version.

I read that normally the MSI should remove the files which version is newer than the existing ones and replace with the new ones. And when I run the previous MSI (those which updates the product from 1.4 to 1.5) it works just fine as described. (I'm not sure with which version of visual studio it was compiled but I guess it's with VS2008).

Now when I run my MSI, it seems that it first runs the "installation sequence" that replace the old .exe with the new ones, and then it runs the "uninstall sequence" that erase the .exe. And when the install is "finished" there is no more .exe in my application directory. (However in the "Add/Remove Programs" Panel the product apppears as installed in version 1.6).

(NB : I can notice when the "install" part or "uninstall" part of the MSI is running because both have Custom Actions that open a Console Application in which I can have a trace).

After more research I compared the old MSI with mine whith ORCA and I noticed differences in the table InstallExecuteSequence :
With the old MSI, the sequence number of RemoveExistingProducts is 1525 that is between InstallInitialize (1500) and AllocateRegistrySpace (1550).
With my MSI, the sequence number of RemoveExistingProducts is 6550 that is between InstallExecute (6500) and InstallFinalize (6600).
I can't see any other differencies in the table.

I even tried to edit manually with ORCA the MSI and put the sequence number of RemoveExistingProduct to 1525. At the execution the "uninstall part" ran correctly but then I got a 2356 Error (after a few research I guess this is because editing manually the MSI corrupted it).

If anyone have an idea that explains the behaviour of my MSI and how to fix it?

Thanks

2
For more precisions : I tried with RemovePreviousVersion at False, then the update ran fine and at the end my product was updated correctly. But in the Add/Remove Programs panel 2 occurences of the product appears, one in version 1.5 and the other in version 1.6. Trying to uninstall the version 1.5 do the same effect than the MSI compiled with RemovePreviousVersions=TRUE, that is the product 1.6 appears as installed but there are no more .exe in the application directoryquinn
thanks.. your question helped resolved my problem of uninstalling previous versions automatically..Lenin Raj Rajasekaran
Probably this is an old post but just for reference for others, I had a similar issue and noticed that changing the assembly version number of the Project file solved this issue. So before a new install project is build, version number of all other projects that has changed also needs to be updated.rageit

2 Answers

3
votes

This appears to be a bug with the plugin "Microsoft Visual Studio 2017 Installer Projects". The msi file gets built with an incorrect sequence number (too high). The uninstall of older products happens after the install of new files, so new files get incorrectly deleted.

Manual fix: Change the sequence so that uninstall of old products happens before the install of new items.

  • open the msi with orca.exe (or whatever editor works for you)
  • go to the InstallExecuteSequence table
  • change the RemoveExistingProducts sequence number so that it is between InstallValidate and InstallInitialize. For example, I changed it from 6550 to 1450.

I ended up creating a simple script to do this fix automatically as a post build step. You can get on github it here... InstallerStuff

0
votes

That article is just out of date in two respects:

  1. It doesn't explain that the upgrade in later versions of Visual Studio setup projects was changed to be "on top" of the existing files, after which the older product is removed. This is not a bug, it's a feature. Example: If you installed a product with a database that was then populated by the customer with a million database entries, then the old upgrade removed it before installing the new version of the product.

  2. Because the new version is installed over the older version the file replacement update rules are applied, such as newer versions replace older versions (based on file version) and files modified after first install are not removed (so preserving our hypothetical database).

https://docs.microsoft.com/en-us/windows/desktop/msi/default-file-versioning

Having said that, this doesn't appear to be the cause of the problem. If you upgraded from VS 2008 to VS 2010 it sounds like you have this issue:

https://support.microsoft.com/en-us/help/2418919/fix-files-and-registry-keys-for-the-installation-path-disappear-unexpe