1

I am looking for a way for providing customers with hot-fixes and patches of my product.

The patch could contain one or more hot-fixes, and customer should be able to check/uncheck any of hot-fix(es) from a list during the update installation.

Every hot-fix may contain operations like:

  • Add/Remove/Replace file
  • Start/stop service(s)
  • SQL scripts to run
  • Delete/Write/Update registry entries
  • Update configuration file(s)

There are several options how it could be done:

  • Get all the hot-fix content compressed within zip and provide it to the customer with appropriate instructions how to install it. This is not an option, cause installation engineer needed and even makes very bad impression about the product.
  • Create installer using some Windows Installer based technology (Wix, for example). Takes ages to create a simple installer, requires deep and strong knowledge of Wix framework, etc.
  • Use Wix Creating patches feature, which basically compares two MSIs and creates new one with content which differs. Looks acceptable and promising, but seems like cannot detect changes in SQL scripts, registry keys, etc.
  • Use 3rd party tool. I have not managed to find any appropriate tool, which can simplify the hot-fix creation process, and I am not going to ask for one, since I know this would be off-topic on this site, but I would like to mention this option for completeness.
  • Write brand new tool which will help to build hot-fix MSI. Still believe that some better approach already exists, cause it is wide spread task to create a patch or hotfix.
Improve this question
8
  • Well, I don't know your product and if it makes sense to let the customer interactively decide about which fixes to install, but are you aware about the risk of creating an unmaintainable installation mess on the customer's production site? This is IMHO only acceptable if the hotfixes are all unrelated to each other and there are no dependencies between them.
    – Doc Brown
    Commented Sep 11, 2017 at 15:11
  • There are a lot of components inside, and customer can chose to apply fixes for component A only installed. So, it is up to customer to control the update process, anyway
    – Alex
    Commented Sep 11, 2017 at 15:17
  • 1
    By the way, here is an approach we use not exactly like that, but in a similar manner: deploy hotfix by WiX as a patch, but only the new files at the application site. Additionally, put the logic for updating the database, registry entries, config files etc. into some kind of update tool which is copied into the application folder by Wix, and let Wix call this tool after the installation in a custom installation step. That gives you much more control and validation options for the critical parts of the hotfix installation.
    – Doc Brown
    Commented Sep 11, 2017 at 15:21
  • Another popular and proven tool for creating Windows installers is Installshield. It also takes time to learn and has its own programming environment.
    – joshp
    Commented Sep 11, 2017 at 15:22
  • @DocBrown, really like your approach, but Update Tool still needed. So it will be a good reason to develop UpdateTool.
    – Alex
    Commented Sep 11, 2017 at 15:33

1 Answer 1

Reset to default
1

My suggestion: you use your favorite installer framework (for example, since you mentioned it by yourself, Wix) to deploy every changed file at the application site, and include a "server update tool" in the MSI package (as an optional component, since it does not need to be installed on every machine where the application runs, or it can be installed separately on an administrator's machine).

The update tool will be run after the installation and do the DB server migrations. Server fixes or patches cannot be done by "detecting difference between SQL files automatically", this is nothing any installer framework I know of can do this for you. Instead, you will typically need a sequence of SQL commands altering your database with regards to the already existing schema and data in there. Such migration commands are best written manually and thoroughly tested before they are executed on a production db.

Registry keys and local configuration files may be handled the same way: either the changes are so simple the installer framework can do them for you automatically, or, if not, include the necessary update steps in a separate tool (or, if no administrative rights are needed for this, include them in the startup process of the application itself).

That way, you get the best of both worlds:

  • a set of files to be deployed with an installer framework with a manageable learning curve, surely not taking "ages", as you wrote, "to create a simple installer"

  • an own tool written in your favorite programming language for doing the complex parts of the hotfix installation (and not a tool for "helping to build hot-fix MSI" packages, the update tool I suggested does not require any MSI knowledge)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.