Aaron Feng

Deployment is an important process of the software cycle. It needs the same level of care as the application itself in order to have a professional and successful product. Deployment needs to make a good first impression. After all, it is the first thing a customer sees.

Deployment itself is a big topic. In this post, I only want to focus on the actual deployment package. Since I'm working on a Windows platform, I will specifically be talking about the Windows Installer technology.

Beside the daily software development, I'm also involved with the direction of our deployment package. As our software matures, the required configuration also increases. The first intuition is to allow the MSI package to do all the configurations. This approachhas several draw backs. These draw backs might even ruin the professional feel of the application.

Let's start off with how one would allow the MSI to do all the fancy configurations. The only way to do it in the MSI world is to use CustomActions (CA). Anyone who has written a CA will tell you it is not trivial to build it reliably. There are several ways CA can be written, but the most robust way is to use unmanaged C++. This requires not only the knowledge of C++, but a solid understanding of the internals of the MSI. On top of that, the UI facility in the MSI is far less simple than standard Winforms. Complicated configurations might require a fancier UI. This will also not be easy to achieve.

Let's say in a perfect world, CA comes for free. The problem doesn't stop here. What if the customer needs to reconfigure the software? Since the configuration is embedded into the MSI, customers would have no choice but to uninstall and reinstall. Even worse, during the uninstall, some machine or user specific files might be lost since the uninstall removes all the files that came with the package. Sure, there must be some way to change the configuration manually right? If the MSI did it for the customerin the first place, I'm sure he/she might have no idea how to do it manually.

I would like to propose a different approach: External configuration tool that ships with the package. The MSI can even fire up the configuration tool after a successful installation. This would solve all the problems I described above, and the code base can be more homogeneous to the application (Assuming you are not building a C++ app). It will be much easier to build an intelligent external tool that can provide real time feedback on any configuration errors. The tool can even receive commandline arguments passed in from the MSI for slient installation.

One could make the argument that the configuration can be done inside the MSI via CAs and still have an external tool to configure the application. You may wonder who would want to duplicate this effort. If you are in the .NET world, you will have to support two different codebases that configures the application.

I think everyone would agree reducing the numbers of CAs can improve the reliability and the compatibility of the installation package.

I'm not saying CAs should be completely avoided, but use them wisely. What I'm saying is the application should be configurable outside of the deployment package.