Alois Kraus


  Home  |   Contact  |   Syndication    |   Login
  133 Posts | 8 Stories | 368 Comments | 162 Trackbacks


Article Categories


Post Categories


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 but MSI will only use the first three digits for version checking. Its format is 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:



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).



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.

posted on Saturday, July 2, 2011 9:24 AM


# re: About MSI Product/Upgrade/Package Codes 7/22/2011 10:35 PM Sukirti
thanks for the is of great use...
I have one question , if a msi was built in 32bit m/c & installed in 32 bit system which was later upgraded to 64 bit then in this case if i give a upgrade msi generated in 32 bit , will that uninstall the 1st msi installed in the other machine (now which is 64 bit).

# re: About MSI Product/Upgrade/Package Codes 7/22/2011 11:50 PM Alois Kraus
Hi Sukirti,
a msi with the same uprade code will try to uninstall the other regardless of its bitness. If both are 32 bit it will work just fine. The OS may change but for 32 bit msis nothing did change for the usual upgrade path.

# re: About MSI Product/Upgrade/Package Codes 7/24/2011 11:29 PM Sukirti
thanks a tonn more thing,the 1st version of my tool was configured only for per user install now i want to give them a upgraded version & i want the MSI to uninstall the previous version & install the new version in one far as i know i guess MSI Context(just me or everyone ) matters. so, even if i configure the new version with everyone(all users =2) context it will fail to uninstall the previous there any way to do this...i believe the MSI context should be same ...correct me if i am wrong...thanks in advance!!

# re: About MSI Product/Upgrade/Package Codes 10/20/2016 2:56 AM Srinivas
thanks for the info,
I have one scenarion where 32 bit application(msi) present in the machine , after that I am upgrading to 64 bit application via command line , upgrading is happening properly but 64 bit binaries are copying to 32 bit location i.e, programfiles(x86) location instead of programfiles. so what could be the possible solution, we are using installshield to generate the msi's.

# re: About MSI Product/Upgrade/Package Codes 10/20/2016 4:49 AM Alois Kraus
You need to create a new msi with a different product and upgrade code than the existing one and fill in the Upgrade table the upgrade code of the existing msi to uninstall the x86 edition. That is how the final msi must look like. I do not know how Installshield can do this but you should consider the WIX toolkit which makes it pretty straightforward.

# re: About MSI Product/Upgrade/Package Codes 4/6/2017 1:54 AM imran
Product code And upgrade code will appear on Install Shield
General Information,But where is the package code appear in general Information.

Post A Comment