Installation process for a modern complex Windows Software Installation?

Question

We're trying to re-think the installation process of our software suite and I'm trying to find out what specific pitfalls we're facing without using my/our limited lens of the Windows software landscape today.

We have gathered a set of issues that an installation of our software potentially has to handle, and I would like to gather whether these points do make sense to consider in the context of a Windows installation procedure, or whether some of those points are better left outside the context of the installation procedure.

We face to issue, for at least a subset of the application suite, to at least do the following:

• Require running 3rd party DMBS on the machine
• Pre-Install .NET Framework or vcredist or other system-wide resources
• Put Files into SystemDrive:\Program Files
• (Optional) Automatic Update (of Program Files, ...) when launching some applications
• Put an Icon into the Start Menu / Desktop
• Install and maintain Windows Services
• Edit registry keys pertaining to our software (i.e. HKLM\SOFTWARE\OurShpo\...)
• "Installation" should work on Windows 7 and all versions, including server and LTSB, upwards
• "installation" should be optionally automated / no user interaction.

Is there any best practices on what and how to put these things into the installation process / or installation tools. What parts to keep hand off completely and what parts to better implement inside the application. (e.g. file-extension association is one point where I am very unsure who's job it is to fix this up.)

Disclaimer: I'm not interested in the toolchain per se here. I know there's InnoSetup, WiX, NSIS, ... and all of these can achieve some - or all - of these points somehow. The problem is deciding which of these points raise which (conceptual) problems on different Windows versions or which points don't actually make sense to put into our installation process.

Answer 1

From my experience of over more than 10 years of Windows product development, I would recommend to put almost everything above into an MSI based installer, if you want to make it easy for the admins who have to install your software. This definitely includes "file-extension association" (which may require administrative rights in some environments, so it is not a good idea to implement this inside the application).

For .NET framework or vcredist installations, Microsoft provides ready-made installer packages you can distribute with your software and embed into your own installer.

For third party software like a DBMS, it really depends on the specific system, the license terms, what the vendor provides and which customizations you need. It makes also a big difference if you provide a central server installation, or just a local DB installation on the machine where the application is installed. But all major DBMS vendor provide documentation for the deployment, so you better check those.

Your goal should be to automate most of the installation steps. For our system, over the years, whenever we saw a manual configuration step, we asked ourselves

• "is there a chance to let the installer do it automatically?"

• "if not, is there a chance to make the procedure less error prone, maybe in a semiautomatic fashion?"

For example, the installer can often check in the registry which other required components are already installed on the system, or in which locations those components are installed, or which versions they have, which is often crucial for implementing automation. Another approach could be to provide certain tools purely for administrative purposes. For example, scripts or maybe a GUI tool for starting, stopping and validating certain windows services without having to learn cryptic command line parameters.

Regarding "Windows version": it is surely better if you don't need different installation procedures on different Windows versions, and try to develop your application version-agnostic. However, if you have 3rd party components to install, you do not always have the full control over it, and if you cannot avoid such steps, the installer can check the version and act differently.

Something you should implement in the application is some validation of dependencies or configuration file entries, and clear error messages in case something fails. People should not have to guess around when someone accidentally misconfigured the system during or after installation. Try to make it easy to find the root cause of such issues. Show (or at least log) somewhere which file is missing or has the wrong format, which config entry is malformed, or which 3rd party component has not the version you expected.

One thing you should have a look at are DB schema upgrades. For a local DB, the application may do the schema upgrade automatically, when required. On a central DB server, however, such upgrades may require a separate upgrade installer package, and instructions how to install it, which may include bringing the DB offline for a certain time interval. If your application requires a certain schema version, it should check at program start if that version is installed, and if not, show a clear error message. Do not show just a braindead text like "There is something wrong, ask an admin". Instead, show (or log) something like "Error detected, the connected database has version 23.45, but the application requires at least version 24.00 - please ask an admin." Even if the users cannot directly use this information, they can send the message to the support hotline, which gives the staff the required information of what went wrong.