When you generate an MSI you need to set at least
Upgrade code is not mandatory but in reality it is also a must or you will not be able to create upgrade msi packages. One interesting thing about ProductVersion is that you can choose to set a 4 digit version like 1.1.1.0 but MSI will only use the first three digits for version checking. Its format is major.minor.build. This is important if you decide to create a update or upgrade package. Have a look for the rules when to change version and product code. The codes are all in form of a guid like component ids of the form
- {12345678-ABCD-EF12-1234-123456789012}
Allowed characters are 0-9 and A-F. The codes must contain only upper case letters. The behavior is undefined if you do not stick to this convention. To generate such a guid you can use Guidgen from Visual Studio. Beware of Guidgen versions previous to VS2010. They had the issue that from time to time it smuggled lower case letters into your guid.
Alternatively you can use Powershell:
"{"+[System.Guid]::NewGuid().ToString().ToUpper()+"}"
Package Code
The easiest code is Package Code. It does change every time you create a new package. When you install a package and generate a new one with <insert your favorite packager here> and then you try to uninstall it by right clicking on the new package you get an error box that another version of the product is already installed. This is the only reason I know of why the package code does exist.
Product Code
The product code identifies your msi with a unique guid. It must be the same for all patch versions (the first two digits of the version are the same). When you create a new product version e.g. a 2.0 and want to install it side by side with the old version you will not succeed. MSI will tell you that another version of your product is already installed.
Upgrade Code
Since you know know that the product code needs to be changed between major versions we need another code to identify a product line. Imagine e.g. Office 2003 and Office 2007. Both major versions need to be serviced (patched and upgraded) independently. Here you assign Office 2003 one upgrade code and Office 2007 another one. Now you can create patch and upgrade versions for both product lines independently although each office upgrade will get a new product code. All Office 2003 msi files regardless if first release, patch or upgrade version will receive the same upgrade code to enable upgrading of any previously installed Office 2003 version.
32/64 Bit Issues
What could possibly go wrong? Well it turns out a lot if you do not pay close attention to your product and upgrade codes.
Product Code
If you release a 32 and 64 bit version of your msi but you do not change the product code between versions you will find out that you can only install either the 32 or the 64 bit version but not both.
Upgrade Code
If you create two unrelated msi files with the same upgrade code (copy and paste is soo easy) and try to install both you will find that the second installation will uninstall the first msi. Why? If your msi files do contain an upgrade table, a FindRelatedProducts and RemoveExistingProducts action then your second msi will find a previous product with the same upgrade code installed and will simply replace it.
If you have the same upgrade code for 32/64 bit versions of your msi then you will run into the scenario above. This is especially nice if a 32 bit msi tries to uninstall a 64 bit msi which are installed into Program Files and Program Files(x86). Windows file system redirection will redirect changes from a 32 bit msi process from Program Files to Program Files(x86) which causes totally undefined behavior. After the “upgrade” from a 64 bit version to a 32 bit version of your application both versions will be unusable and the installer database is almost certainly corrupt.
Component Id
Yes component ids must also be different between 32/64 bit versions of your msi. This can also cause funny things like left over files after uninstallation of your 32 bit msi because the 64 bit msi does still reference the component although the component does point to different files residing under Program Files and Program Files(x86).
Conclusion
It is a very good idea to change all guids (product code, upgrade code, component ids) between a 32 and 64 bit build of your msi or you will experience funny errors. One way to get around these issues is to generate these guids automatically by your packaging tool so you do not forget. A very easy “algorithm” is to increase the first digit of any guid for a 64 bit msi build to prevent such issues.