InstallShield: Suppress Restart Messages in the middle of Software Upgrade or Uninstallation

I'm back to Installation development in this post. This time, I'll show some personal tips to get rid of restart recommended messages in the middle of software upgrade or uninstallation. First of all, let me make it clear. This is just a temporary solution under some specific conditions and trade-offs. I won't seek for a perfect solution in this post. Should you do, I don't think this post will be helpful for you. You can save your time by looking for other sources on the Internet instead. 

How much do you want to eliminate these annoying popping up messages during major upgrade or uninstallation progress?

I guess you want to get rid of them as much as I do. That’s why you hit this blog post. I've been reading back and forth this post http://buildmaestro.wordpress.com/2011/03/14/suppress-filesinuse-dialog-on-uninstall/ many times before I came up with a solution on my own. It's a nice post. If possible, try to read it. Whatever the author describes in that post was exactly what I have seen in my current projects. Therefore, I noticed his two suggestions:

1. Add some delay (10 second Thread.Sleep) after he manually stops the services
2. Completely disable Restart Manager (Property Name: MSIRESTARTMANAGERCONTROL, Property Value: Disable)

The first solution looks tempting because it's very easy. However, it doesn't work for me at all. No matter how long I've been waiting, the restart messages (or FilesInUse dialog) are still popped up. They even pop up earlier than my custom action which is used to kill my services manually.

For the second suggestion, I definitely don’t want to disable Restart Manager since it’s better to reboot the machine than missing locked files and crashing the application at the end. 

I was like killing myself over those dialog boxes until I saw this link http://blogs.msdn.com/b/hemchans/archive/2006/09/15/756728.aspx (on the blog post above but at the end).  I've learned from the MSDN blog that File Costing is the guy marking my services and reporting a restart request to Restart Manager before my custom actions are performed.  No matter that I put my custom action to kill services manually very early in UI sequence, as long as the custom action is triggered after CostingInitialize, Restart Manager will throw all “nice” restart messages above. 

What should I do? Well, very simple, right? Just move my custom action higher than CostingInitialize in both UI and Execute sequences. By doing that, my custom action will be given a chance to execute before File Costing phase. Therefore, my services are all gone before they're reported to Restart Manager. Beautiful! But...., let's wait a second to think a bit here. Is it good to do that? I'm glad you ask!!!! 

I mean, that was truly the solution I'm proposing in this post. However, there are some drawbacks I would like to point out here so that you can consider more. First of all, it's not accepted as a best practice to move your custom action higher than File Costing phase. If you're a fan of best practices and never accept exceptions, you won't take a chance for it. Second, you can move your custom action higher than File Costing if and only if you don't need to use MSI properties to control your custom action. If you do, those MSI properties are not assigned values yet. Your custom action won't run as your expectation. For example, you may want to kill your services if you perform major upgrade only. In this case, you need to use such conditions as IS_MAJOR_UPGRADE or UPGRADINGPRODUCTCODE to guide your custom action. If I remember it well, IS_MAJOR_UPGRADE won't be assigned a value until InstallValidate is called (http://msdn.microsoft.com/en-us/library/windows/desktop/aa369786(v=vs.85).aspx), which is too late. In case you want to know, here is the default sequence between CostInitialize and InstallValidate: CostInitialize -> FileCost -> IsolateComponents -> CostFinalize -> SetODBCFolders -> MigrateFeatureStates -> InstallValidate. 

At least, I could apply this workaround for some critical projects which require non-interactions from end-users during upgrade. I have to accept trade-offs. For projects with leeway, I will consider more before applying this approach. I hope you can take it as an option. Enjoy working with installation development!