hcUpdateFramework - The Server Side

As promised, in this article I will be describing the server side components of the hcUpdateFramework, namely:

  1. ClientUpdateService
  2. Launcher
  3. Register
  4. AutoUpdateServer
  5. Update Manager

4. AutoUpdateServer

The AutoUpdateServer is a Windows application that exposes the IUpdateService SOAP service on port 8080 by default.  It can be compiled as an ISAPI DLL, a Win32/64 VCL Application or a Win32 NT Service running under the local system account.  Most of my implementations have simply used the VCL server application so YMMV.

The server process sends an update to the ClientUpdateService when it checks using the IUpdateServer.GetUpdate method. The service creates a default INI file the first time it is started, if one does not exist. The INI file contains the following settings:


This service can be compiled as a Win64 NT Service, but currently throws an I/O related exception in the utility methods used for binary file streaming.

Updates are created in subfolders under the Updates folder located in the same directory as the update server.  All updates are static, meaning the contents of the update are determined when the update is created and not on a per request basis from the client (although that is technically possible). In order to reduce the bandwidth and server utilization, binary patch files are supported using Microsoft’s delta compression technology.

Currently, there are two databases supported; SQL Server (via ADO) and Firebird 3.X (via FireDAC).   The SQL Server schema needs to be updated to mirror the changes made when migrating the server to Firebird.  Once that is complete, the FireDAC datamodule could be modified to support both databases.  Scripts for all supported databases can be found under the SQL folder, including scripts to create new deployments in the database without using the Update Manager.

5. Update Manager

The UpdateManager is an application I wrote to automate the creation of updates for a given application.  The framework defines an application as a primary EXE which is entered into the list of registered applications in the Deployment database and whose version drives the update version (they usually match).  An application deployment may contain other EXEs, and supporting files which are detailed in the XML Manifest file which contains:

  • UpdateVersion - version of the Update (often matches primary EXE)
  • WhatsNew - RTF description of what has changed in this update
  • IsMandatory - update must be applied (user is not given a choice)
  • IsSilent - update is applied without presenting a UI (ClientUpdateService)
  • IsImmediate - update is applied immediately after download (ClientUpdateService)

1..N of the following where N is the number of deployment items aka application components:

  • FileName - target filename
  • Version - version of the file
  • TargetPath - location to copy the file into in case it differs from the application folder
  • IsAPatch - this file is a patch file to be applied using MS Patching
  • IsAZip - this file is compressed using the Zip archive format
  • Launch - launch the EXE when applying the update

An example manifest is:

<Manifest LocationGUID=”2bc5cc04-2307-41ab-9f3c-b3f8c0578be9 ApplicationGUID=”8BF6627D-CB05-4601-996E-072DC6785F81 UpdateVersion=” WhatsNew=”Incorporated Auto Update IsMandatory=”false IsSilent=”false IsImmediate=”false>
<Item FileName=”MyApp.exe Version=” TargetPath=”{app} IsAPatch=”false IsAZip=”false Launch=”false/>
<Item FileName=”App Manual.pdf Version=” TargetPath=”{app} IsAPatch=”false IsAZip=”false Launch=”false/>
<Item FileName=”Manifest.xml Version=” TargetPath=”{app} IsAPatch=”false IsAZip=”false Launch=”false/>

An Update on the server side consists of a root folder called Updates under which subfolders are created for each update version using the same naming convention used on the client as shown:

Updates Folder Structure Server Side

Updates Folder Structure Server Side

Within each update folder, there must be a manifest and all files appearing within that manifest.  Once the update folder is created with all the necessary content, a new deployment record must be created and new InstallationDeployment records need to be created in the database and then enabled to distribute the new deployment/update to existing installations/users.  The SQL to do so is present for Firebird so updates can be manually crafted, but it is much easier to use an UpdateManager.  Unfortunately, the current implementation requires the DevExpress ExpressQuantumGrid and Editors.  With the database changes made during migration to Firebird I will also need to update the hcOPF domain objects to reflect the current structures.

The hcUpdateFramework needs some TLC and can certainly benefit from some new ideas, but it is a functional, proven update framework that can be extended in many ways to facilitate your deployment needs.  I am open sourcing it, in the hope that others will contribute and make it a more complete, modern solution.

Leave a Reply