View Full Version : What is a Hotfix?

10-28-2005, 05:13 PM
I have gotten involved in the "Release Management"/"Release Engineering" for a company with existing products. During various discussions one topic keeps popping up... When one has a customer with product installed, the customer reports a problem, development finds and fixes the problem, if its urgent to get the fix to the customer, the delivery vehicle is the "hotfix". I should note that the product is installed via an InstallShield Basic MSI project, and upgrades are forced to always be Major Upgrades.

A hotfix is some form of installer that replaces distributing the naked revised file, say a .dll, and then asking the customer to drop the .dll into the right directory(s). Thus, a hotfix consists of a "wrapper" around one or a small group of files that are needed to fix a single issue. When installed, a hotfix's presence is visible on the Control Panel's add/remove software dialog. If the product is uninstalled, the product along with all hotfixes gets removed. When a product upgrade install is performed, all of the hotfixes applied to the prior product install/upgrade "disappear", and the only thing visible in add/remove software is the product. This is the behavior various stakeholders have for the item named a "hotfix".

I am wondering:

1 - How the heck does one implement this defined "hotfix" behavior?

2 - Does this match the "hotfix" definition YOU have, and if not, what are the differences and underlying rationale?

I believe this definition is derived from people's observations of what happens when they apply the latest changes to their Microsoft software. Thus, they presume the standard Microsoft tool (Microsoft Installer) must allow any software developer to use the same tools to achieve the same behaviors.

3 - I don't think the the Microsoft Installer is used by Microsoft to achieve this "hotfix" behavior? It seems like they combine usage of the Microsoft Installer with the Package Installer, for which I've only found user documentation... nothing for how one might use the beast... and thus its not easy to "just do what Microsoft does'?

Christopher Painter
10-28-2005, 06:10 PM
A hotfix is just a way of saying priority urgent patch. It's often seen as an interim solution that will be incorporated in a later build or cumulative roll-up patch.

Microsoft Office for example is an MSI based product and there hotfixes are typically distributed via ohotfix.exe which is a boostrapper that calls a specially generated MSP. Then later a service pack will be release which also contains the same logic as the earlier hotfx.

Some organizations don't plan for emergency hotfixes very well and you'll see all kinds of quickly prepared patching solutions that are literally invented on the fly to solve the urgent problem at hand. Other organizations ( for better or for worse ) are used to getting themselves into situations where they frequently need to provide hot fixes for fielded production systems ( not naming any names LOL ) and they have very well defined processes for releasing these types of patches.

Personally I prefer to have a well defined process in place and then never need to use it!!

Even if you release your product as a series of major upgrades you can still generate interim patches. If you manage your baseline well you can even generate production builds while maintaining a seperate development branch. You could build your major release from the production branch and distribute it as such. The reason some people prefer patching is the patches are smaller, faster and easier to know 'what's in it.' The reason some people prefer full releases is that you know they won't miss any inbetween changes.

10-31-2005, 03:54 PM
Maybe this is not obvious, but I am attempting to do that planning for hotfixes now while there is no emergency. I tried to take a look at a Microsoft Office hotfix to get some sense of what they are doing and come to the following conclusions:

1 - They do not depend on MSI for much functionality. There are a large number of custom actions, most of which either call into install related DLLs or execute programs with install command line arguments.

2 - The complexity is so great, and so much logic is hidden in the DLLs and executables, that I'm not sure what I can learn from this example.

3 - I'm not sure how I separate the patch details in the .msp from the installer details in the .msi file? Any pointers would certainly be appreciated.

So, I go back to my original posting on this topic and ask:

- How do I issue a hotfix that is treated as part of the fixed product when the user either uninstalls or performs a major upgrade?

- If a hotfix needs to be a patch, how do I minimize the files affected? Right now, the product uses a "clean-tree" build process that fetches files from the SCM tool and then builds the complete product. A "patch" that reflects the deltas between the original release build and a full rebuild would seem to include every file, if for no other reason than to capture all of the new compile dates as well as the new version number (if nothing else, the build number is new)?

I am at the point where I can define new process and/or tools, so I just need to understand what I need as the output of the build process to accomplish the desired Hotfix behaviors I already described?

Christopher Painter
10-31-2005, 04:43 PM
Actually most Office hotfixes are simply .MSP's wrapped using Ohotfix ( a custom inhouse boot strapper )

You can generally use the /c /t arguments to extract the patch and see the INI that tells OHotFix how to process the MSP.

Occasionally you will see custom stuff in there ( like adding a new DLL that didn't exist during the last release ) that MSI won't let you do.

You can use InstallShield to generate a patch starting from a given reference install ( you can't build a single setup.exe though, the previous build must expose the MSI file ) but your right, if your SCM process performs a full rebuild it can be difficult to isolate what has changed since everything has changed.

10-31-2005, 06:00 PM
Can you describe in excruciating detail how InstallShield decides which files have changed when its generating a patch?

Also, if I go with a patch install, will it behave according to the hotfix behavior I described in my initial posting in this topic? If I have foo 1.0.0 installed, then apply hotfix 1 (let's call it foo 1.0.1), will uninstall of foo 1.0.0 also uninstall my hotfix? If instead of uninstalling, I next install a major upgrade to 1.1.0, will THAT replace both 1.0.0 and the hotfix 1.0.1?