如何正确生成 Visual Studio 安装程序（并删除旧程序）
总结，每次正式发布前，AssemblyFileVersion必须更新版本号，安装程序项目的 Version 也必须更新，由于 AssemblyFileVersion 与 Version 的格式不一致：
Version 保持与 AssemblyFileVersion 的前三部分一致
How to install a new version of a deployment project over old version
1.Set Remove Previous Installation as True
2.Set Detect new version as True
3.Your C# program's version must increase with every deployment
4.You should change version of your installer to one higher version and it will ask you to change product code, select YES.
5.Do not change your upgrade code, let it be same.
What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?
Where other assemblies that reference your assembly will look. If this number changes, other assemblies have to update their references to your assembly! The AssemblyVersion is required.
I use the format: major.minor. This would result in:
Used for deployment. You can increase this number for every deployment. It is used by setup programs. Use it to mark assemblies that have the same AssemblyVersion, but are generated from different builds.
In Windows, it can be viewed in the file properties.
If possible, let it be generated by MSBuild. The AssemblyFileVersion is optional. If not given, the AssemblyVersion is used.
I use the format: major.minor.revision.build, where I use revision for development stage (Alpha, Beta, RC and RTM), service packs and hot fixes. This would result in:
The Product version of the assembly. This is the version you would use when talking to customers or for display on your website. This version can be a string, like '1.0 Release Candidate'.
Unfortunately, when you use a string, it will generate a false warning -- already reported to Microsoft (fixed in VS2010). Also the Code Analysis will complain about it (CA2243) -- reported to Microsoft (not fixed in VS2013).
The AssemblyInformationalVersion is optional. If not given, the AssemblyFileVersion is used.
I use the format: major.minor [revision as string]. This would result in:
[assembly: AssemblyInformationalVersion("1.0 RC1")]
Visual Studio Installer Projects and “Previous Versions”
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…