This tip applies to Visual Studio 2008 and Windows Installer (Setup) Projects. They’re used to create *.msi installers for deploying applications.
I was having some weird issues with my setup project. When I tested the installer against the previous version of the installer, it would run fine without reporting any errors, but when I launched my application, the changes I made weren’t showing up.
Odd, I thought. I figured the installer wasn’t working properly. What I was expecting was an uninstall to show up before the install ran. This is actually the behavior in Visual Studio 2005 setup projects. It’s different in Visual Studio 2008.
Problem
I incremented my setup project’s Version from 1.0.0 to 1.0.1, thinking this was good enough for the installer to upgrade a previous installer and grab the new application files.
If you investigate further, it will become apparent that the installer did indeed run. You’ll also discover that none of the application’s assemblies or other files have been updated after running the installer.
As I briefly alluded to above, you apparently wouldn’t have this problem in Visual Studio 2005 due to the behavior of the legacy installers. They actually do run an uninstall on the old installer, and install the new version. Visual Studio 2008 behaves differently.
Solution
There are two important steps to get the installer upgrades working properly in Visual Studio 2008.
- Increment the Deployment Project's Version
For example, if your current version is 1.0.0, change it to 1.0.1
- Increment the file versions
[assembly: AssemblyVersion("1.0.0.1")] [assembly: AssemblyFileVersion("1.0.0.1")]
In Visual Studio 2008, a file version comparison occurs when the new installer runs against an older installer, replacing anything that has changed rather than running an uninstall/reinstall. Overall it’s much nicer for upgrades, but confusing if you don’t know what’s happening and forget to change the file versions like I did.
General Rules About Installer Upgrades in Visual Studio 2008
Old and new products must have identical UpgradeCode values and different ProductCode values.
Old and new products must have identical values for InstallAllUsers.
New product's setup Version (the setup project, nothing to do with file versions) must be higher.
All setup versions (again, not file versions) must be 1.0 or greater.
Visual Studio 2008 RemovePreviousVersions is not the same as 2005 and uses file update rules. Therefore if you want to update files you must increase file versions. This is normal practice in all setups, patches, etc. that file versions are updated if they have new content.
- Visual Studio 2005 RemovePreviousVersions behaves like an uninstall of the older one, followed by an install of the new one, and rules 1-4 still need following, but you could get away with not incrementing changed file versions because of the "uninstall, then install" nature of the upgrade.
Thanks go out to Phil Wilson for the information!
Hope this helps someone else