We have a product that we need to create an installer for.
It has a number of components which can be installed or not as the situation demands.
When we ship our installation package, we want to be able to have that include any number of additional components to be installed.
For example, Foo Manager Pro contains:
- Foo Manager Console
- Foo Manager Database
- Foo Manager Services
That might be shipped as something like:
- FooManagerInstaller.exe
- FMPConsole.pkg
- FMPDatabase.pkg
- FMPServices.pkg
A package might consist of something like:
- Manifest
- Files to be deployed
- Additional scripts to be executed
(eg find file foo.config, do some XML Manipulation)
If a client wants to add custom skins and a series of plugins as part of the install, they create their own packages:
- FMPConsoleSkins.pkg
- ClientWebservices.pkg
If that client then ships it to someone else who wants to add more customisation – they can do so in the same way.
We can build this from scratch – but wanted to check if this sort of install system already exists.
We already have a set of NAnt scripts which do something not too far from this. But they’re difficult to maintain, and quite complex. They don’t offer any of the ‘niceties’ that we’d expect from an installer (like tracking deployed files and removing them if the install fails).
We’ve been looking a little bit at NSIS and building MSIs using WiX, but it’s not clear that these can offer us the capability for downstream to provide additional packages, without inventing our own installer language.
This response only addresses Windows Installer (and thus WiX); I’ve never had opportunity to use NSIS.
Windows Installer itself is not well-suited to this sort of extensibility. If you want the full support for resilience (self-repair, advertisement, etc.), then the files added downstream must be added with a transform or a patch, and must be available in a cab or uncompressed on the source filesystem. For this to be a seamless install for the end user, the bootstrap will need to identify these extensions and apply them as part of the installation. However if you ever expect to patch the core install, the idea of having to account for downstream patches is a frighteningly complex one.
If you do not need Windows Installer’s resilience, it’s certainly possible to implement various install and uninstall steps as custom actions. These actions could read your custom pkg format and manifests, and act accordingly, at least for install. Figuring out how to store or recreate the information for uninstall will be key. Assuming you support per-machine (as opposed to per-user), these actions need to be Deferred (In-Script), and thus will have minimal contact with the properties and directories available to the install – research CustomActionData if you want to head down this route. (But watch out; the first hit I saw in a search was to a less relevant “Deployment in Visual Studio” topic.)