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 unin

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 aware I'm sure: Major.Minor.Build.Revision. 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

I came here to get help to same problem. After reading linked incredible useful article I suppose my problem was, that I had installed previous version with "Just me" option and the new installer had InstallAllUsers property selected (in Visual Studio project properties). So after uninstalling previous installation from control panel the update now works. Maybe this helps someone.

Answer 3

Don't forget to increment the assemblyFileVersion! If you don't specify the assembly file version then the compiler assumes it to be the same as assemblyVersion. However, if assemblyFileVersion is specified then it must be incremented.

Answer 4

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 5

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 6

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.