InstallShield: Dealing with Major upgrade on a new project?

What is major upgrade? Usually, we require major upgrade if we either add/remove features or we want to force to remove all old files on target system before installing new files. Sometimes, adding components or removing components also require major upgrade. Those are very basic concepts in installation development, especially working with InstallShield (or Windows Installer). You've been doing major upgrade without problems for years on your current projects. Now you need to enforce major upgrade for a new project (previous developed by someone else) and it suddenly doesn't work at all. Checking installation log file, IS_MAJOR_UPGRADE is clearly set to YES. Then why?

(Source: from the Internet)

In my own experience, there are two answers in this case

1. The project has been used 4 digit version number instead of 3 digit version number.
More discussion can be found here on Flexera Forum at http://goo.gl/7PvWn

With 4 digit version number in Major upgrade, installation log still says that IS_MAJOR_UPGRADE   is set to Yes and upgrade is successful, but it's not a valid major upgrade. It ends up with two program items in add/remove program after upgrading. Here are some pieces of log:

IS_MAJOR_UPGRADE is set to Yes:

InstallShield 12:29:39: UpgradeCode: {5EAFE7D6-480F-403B-AAEC-9A31BB001BD3} MinVersion: 2.5.0.00000 MaxVersion: 2.5.2.26485 Language: Attributes: 1

InstallShield 12:29:39: Checking related product {73342386-C4E3-47B6-B605-BBA4DC317BCE}

InstallShield 12:29:39: MySetup 2.5 64-bit {73342386-C4E3-47B6-B605-BBA4DC317BCE} 1033 2.5.2.26480 ***Related***

MSI (c) (BC!04) [12:29:39:238]: PROPERTY CHANGE: Adding IS_MAJOR_UPGRADE property. Its value is 'Yes'.

Upgrade is set to successful at the end

=== Logging stopped: 6/4/2013  12:31:35 ===

MSI (c) (BC:AC) [12:31:35:385]: Note: 1: 1707 

MSI (c) (BC:AC) [12:31:35:385]: Product: MySetup 2.5 64-bit -- Installation operation completed successfully.

MSI (c) (BC:AC) [12:31:35:400]: Windows Installer installed the product. Product Name: MySetup 2.5 64-bit  Product Version: 2.5.2.26485. Product Language: 1033. Manufacturer: My company. Installation success or error status: 0.

MSI (c) (BC:AC) [12:31:35:400]: Grabbed execution mutex.

MSI (c) (BC:AC) [12:31:35:400]: Cleaning up uninstalled install packages, if any exist

MSI (c) (BC:AC) [12:31:35:400]: MainEngineThread is returning 0

=== Verbose logging stopped: 6/4/2013  12:31:35 ===

Currently, Windows Installer only supports 3 digit version number (http://msdn.microsoft.com/en-us/library/windows/desktop/aa370859(v=vs.85).aspx). There are also some VBscript snippets on the Internet helping overload Windows Installer version checking mechanism for 4 digit number. However, I won't use this solution until it's officially supported by Windows Installer. My solution here is very simple, switch to 3 digit version number. It's a bit troublesome in reading version number since we name out packages with 4 digit version number. However, it still works for us at the moment.  

2. The project has many dynamic-linked components

I've observed a very tricky case in troubleshooting recently. The fact is that, my major upgrade works perfectly in in-house testing. All previous files are removed and new files are copied into target system correctly. However, from the field, there are still reports saying that upgrade is failed. The number of reports are increasing weekly. I couldn't figure it out until taking one piece of uninstallation log from the field. I found that there were a lot of files and folders couldn't be removed from the target system. Therefore, the file system was mixed randomly between old and new files after upgrading. This causes the upgrade failure. Even worse, sometimes, upgrade is successful but software cannot function. After researching around, I recognized the reason was that all those leftover files and folder in removal were dynamic-added components. The issue can be detected mostly on real systems in which data has been using daily and many other software installations has been done after ours. That explains why the issue cannot be detected in our testing. It's too bad since there is still no official way to fix this case unless I convert the entire project to static components. Some ad-hoc fixes have been proposed on the Internet as well, but they require some trade-offs in management later on. After considering all side-effects, I also use one of those ad-hoc fixes. I inserted an installscript function right after RemoveExistingProducts custom action to scan and remove unwanted leftovers. Once again, this solution may cause the least headache in my case, but it may not necessarily work for you. When we come to ad-hoc fixes and trade-offs, there is no right or wrong. It's just the matter of choice, pick the one which works best for you.