I’ve never really taken the time to learn the exact logic the VS installer projects go through when installing a “newer version” of software. We just had the question come up here again, so I decided to investigate. There is a ton of information about this online, Google proves that, so here is just my take on boiling it all down to my “cheat sheet”.
Setup Project – Properties
Version – you should change this to match the version of the new software you’re building the installer for. When you change it, you get the prompt that you should change the ProductCode.
- If answer YES, then the ProductCode is changed (UpgradeCode remains the same – this is how it tracks different versions of the SAME software). Now you have to worry about the RemovePreviousVersions and the file versions of each assembly you’re installing.
- If answer NO, then the ProductCode is left the same, and users will get the “you must uninstall the existing version” prompt at install time.
The “cheap” way out here is answering NO. This forces the user to uninstall any previous version and then they run your newest installer. You are guaranteed (mostly) that all the new files will be laid down since the previous versions have already been removed.
RemovePreviousVersions – If this is True, the installer will first run the “uninstall function” on any previous versions (different ProductCode) of the same software (same UpgradeCode).
- Uninstall function is pretty nebulous. It sounds like it’s going to physically uninstall all the files, but it’s really not. At least since VS2008, it does a “smart file compare”…
- First let’s assume you’re installing to a new physical location (maybe a “versioned” directory structure). In this case, the entire directories for old versions will be removed and the newest version will be copied to its specific directory. That’s kind of a bummer to have versioned directories though (especially if you have data files laying around in that dir)
- If you’re installing to the same directory as the previous version, then it get’s a bit more hairy. When the new installer has files of the same name as the previous versions, it COMPARES FILE VERSIONS of those files to decide whether to overwrite or not. So … you have to be super detailed about updating AssemblyInfo.cs AssemblyFileInfo atttributes on ALL assemblies in your software. This can get painful if you’ve got many projects/assemblies involved. If you’re in this boat, you definitely need some kind of build process to auto-increment the versions of all assemblies.
For now, my cop-out answer is to upgrade the installer project Version and answer NO to the prompt (keeps the same ProductCode). Shift the pain to the user, right?! 🙂
Up next: I’m working on an automated way to update all the AssemblyFileInfo attributes in a whole tree of projects, using the Community MS Build Task called “FileUpdateTask”. Stay tuned…