VS2008 Setup Project: Uninstalling the previous MSI

Question

I have a VS2008 setup project, which creates a setup.msi which installs a WinForms application (C#).

Every time I update the version number, the users first have to uninstall the previous version before they can install the new one. Otherwise we get the dreaded "Another version of this product is already installed" message.

This is what I'm doing already when I build a new version of the installer:

• Set RemovePreviousVersions=true and DetectNewerInstalledVersion=true
• Increment AssemblyVersion (of the exe that's being deployed)
• Increment Version (of the setup project)
• Generate a new ProductCode (as prompted by VS, when the Version is changed)
• Leave UpgradeCode unchanged

And yet it still refuses to uninstall the previous version. So, what have I missed? Or what am I doing wrong?

Thanks!

Answer 1

I am not 100% familiar with VS 2008 setup projects (I use Advanced Installer myself- HIGHLY recommend it BTW; they even have a freeware version!), but I have run into this before and it's not documented very clearly.

There are 4 parts to the version number- as you are well I'm sure: Major.Minor.Build.Revision. Well, the REVISION is NOT checked by windows installer! If all you're doing is incrementing the revision, it won't work. You have to increment at least the build of the ProductVersion value.

Hope that helps!

Answer 2

To have it install over the previous version:

1. Highlight the setup project.
2. Press the F4 key for properties. (Right Click is a different properties box.)
3. Change Version. Say yes to the prompt asking to change the product code.

Keep in mind, even if you rebuild the solution it doesn't rebuild the setup project. You need to rebuild the setup project as a separate step.

Second, you don't need to Increment AssemblyVersion every time. Set it to something like 2.1.* and it will do it automatically.

Answer 3

Semi-answering my own question, just for the benefit of anyone who's interested:

Firstly, I found an incredibly useful article on how MSI updates work.

Secondly, I found InstEd, a rather nice freeware MSI editor, which showed me that there was nothing obviously wrong with my MSI file. (Yes, I could use Orca instead, if I didn't mind downloading the whole Windows SDK to get it.)

Thirdly, and annoyingly, the original problem seems to have fixed itself and I can't reproduce it any more. If it comes back, and if I fix it again, I'll add a comment here!

Anyway, all this brought up a new - arguably worse - problem: the MSI now claimed to update the application but didn't actually install anything! The solution to that is as follows:

• AssemblyVersion doesn't matter, but AssemblyFileVersion absolutely does: it must increment, if you want the new files to be installed. (This is a change in VS2008, compared to VS2005. See, for instance, this discussion on the Microsoft groups.)
• However, AssemblyFileVersion can't autoincrement the way AssemblyVersion can. Setting it to 1.9.* (or whatever) will just result in an error. The solution, from Stack Overflow this time, is to set AssemblyVersion to autoincrement, and then open AssemblyInfo.cs and remove the AssemblyFileVersion attribute altogether. This will force the file version to equal the assembly version.

Answer 4

The Installer service is making decisions based on the contents of the Upgrade Table, so that's where I would look. Does the table have an entry for your upgrade code, does the product version of the currently installed version fall within the range of versions specified for upgrades, do the attributes look ok (for instance, is the msidbUpgradeAttributesOnlyDetect attribute not set), and so on.

MSDN describes it all here - http://msdn.microsoft.com/en-us/library/aa372379%28VS.85%29.aspx

Answer 5

Matt -

Thanks for posting the solution. I had the same problem - "the MSI now claimed to update the application but didn't actually install anything".

My setup project consists of about 10 windows forms applications and as many libraries (about 20 projects in all).

1. Do I need to make the changes in AssemblyInfo for each project? Or is there another way to do this (example, a way to tell the setup project to increment AssemblyFileVersion of all files that are deployed?).
2. What about data files (like config)? How do I make sure the config files from old installation are replaced by the new one?

Thanks, Sam