Introducing Package Reference Counting
These days it’s more common to install products composed of more than one installer package. Modern applications are often a loose fitting of localized components and being authored into a single package just isn’t practical.
For example, a localized application will undoubtedly have neutral or single-language binaries while using satellite resources for other languages’ resources. You could package these common binaries into separate fully-localized installer packages – one for each language – but that will lead to all sorts of problems with shared components.
Having separate packages for common components (core) and for each language’s resources often yields a better installer architecture. Rather than producing, testing, and publishing patches for each fully-localized product (or one patch for all languages, which still requires the same amount of testing), you’ll most often only need to produce a single patch for the common package. Language resources will probably be changed little over the course of an application’s lifetime.
Shared prerequisites like runtimes, third party controls, and the like are also often separate packages you may need to install since merge modules are not separately serviceable and also install shared components.
While this common architecture solves a number of problems, it certainly introduces more problems. For example, if a user installs multiple languages of the same product on the same machine, how do you avoid uninstalling the core packages until the last language is uninstalled? Likewise, if a product is uninstalled will it takes any shared prerequisites with it that other products still require? How do you know if other products still require any packages?
That’s where package reference counting comes in.
Package reference counting, or just ref-counting, is an old design I’ve finally put into practice in recent versions of the Windows Installer XML (WiX) chainer, Burn. The design, however, can – and should – be utilized by any chainer or package that works on a simple premise: you need to opt-into the system or your packages could be prematurely uninstalled.
The idea is simple and probably best reflected in the following example. Let’s say you are installing package B that depends on shared package A. Product C is a third party product that also depends on A, but you’re not really aware of that (as is common). You may think other package depend on A, but don’t know which ones. If both package B and C utilize package ref-counting, you don’t have to worry about package A being uninstalled prematurely.
This feature also allows package A to be upgraded and, as long as they follow the rules I’ll discuss more in future posts, will simply migrate any existing dependents during the upgrade. So if packages B and C dependent on package Av1 and later Av2 is released packages B and C will still be protected.
I’ll go into more details about how to author this in WiX, how other installer technologies can implement and support this feature, and how it’s being utilized today in future posts.
Light
Dark
0 comments