When I first developed the Bespoke Dynamic DNS Updater (then known as the DNS-O-Matic Client.NET), I picked the Visual Studio Windows Setup Project (.vdproj) for creating the installer for the Windows Service. I made this pick based on the fact that it was an included Visual Studio template, and that with the DNS updater being an open source project, I wanted to pick an installer project type that easily configured and consumed by anyone who desires to customize the solution. This was a mistake.
Since I come from a background of web-based development, I was not familiar with all of the options or the benefits or downfalls of the Windows installer projects. What I learned the hard way is that the Windows Setup Project type is seriously lacking in many respects and that it should be avoided.
Reasons for switching:
1) Windows Setup Projects are not MSBuild projects. This is a downside for a number of reasons.
First of all, the windows setup (.exe) installer cannot be built with MSBuild via the command line or a continuous integration server such as TeamCity, or at least not without Visual Studio installed. This means that every time you wish to publish or distribute the installer, you must do it from your development machine. It may be possible to create the installer on a build server, but not without installing Visual Studio, something that I am opposed to.
The format of the file is not particularly readable. When making changes to the setup project such as adding a wizard setup to the installer, the corresponding changes in the project file are not always easily determined, managing a merge situation on this file would be a nightmare.
Because the project file is not in the MSBuild format, you are unable to add MSBuild targets to the project file that are run automatically when building in Visual Studio. While the best practice would be to keep these in an external MSBuild targets file and only generate the installer via the build server, but I like the flexibility of being able to build the project locally in release mode for local testing prior to commiting to source control and running the build.
2) The UI Options are limited to a set of canned templates. If you desire a different combination of textboxes and drop downs, for instance, then are supplied via these template, you are out of luck.
3) Windows Service hung on uninstalling service every time. This makes for a bad user experience, even if only when uninstalling the application. Being prompted to shutdown a service is unnecessary when the user has already indicated that they wish to uninsnstall it.
Why I picked WiX:
WiX is an Open Source project that was initiated at Microsoft. There was clearly a recognition that the existing, free tools were not adequate, including Microsoft's offerings such as Windows Setup projects.
Microsoft has used WiX to create the installers for many of its own products such as SQL Server.
Votive, which is a WiX component, allows you to create a WiX installer with Visual Studio and includes syntax highlighting and IntelliSense.
WiX projects are in the MSBuild format and enable you to create the installer via Visual Studio, the command line or a build server.
WiX enables you to create flexible UI which enables a better or more fully-featured install experience.
While WiX could be awkward at times, it enabled me to accomplish many of the things that I was unable to do with Visual Studio Setup projects, mainly: create project with the MSBuild format, create a more adaptable UI, version the application easily, and uninstall the application cleanly.
Last revised: 10 Nov, 2012 12:00 AM