Now, after the blog is launched we may move on to describe current situation of the software installation world. There is a multitude of software installation frameworks for different platforms and systems: from RPM and DEB for Linux, through tools like InnoSetup and NSIS for Windows to the latest versions of Windows Installer technology. We will focus on Windows Installer, its bright and not so bright sides.

You may have some ideas on why I think both Windows Installer itself and supporting technologies (InstallShield, InstallAware, etc.) do not fit all needs but let us reiterate through the main points once again:

  1. Windows Installer is good at installing files, registry entries, registering services, setting permissions, etc. Windows Installer has some nice features like transations for example. Plus it is heavily promoted by Microsoft (eg. to get Windows Logo certification you have to use WI). Those are the reasons that make you consider using it. But GUI creation just doesn't fit into that picture. Especially given that MSI database describes everything in declarative way while some things (and creating user interfaces is one of them) are just much simpler when using imperative approach. Besides, there are many well established technologies with supporting tools for creating GUI. Why create yet another one?
  2. Windows Installer doesn't support such basic needs as multilanguage setup packages out of the box. Sure you can embed language transform inside your msi file but try explaining that to your customers. Installing multiple msi files is another feature that was missing in older (but still used) versions of Windows Installer.
  3. Most commercial tools for creating installers tend to follow click'n'create approach. While ease of use is certainly an important aspect of any software, in some cases it gets in the way software developers think. The way some products are made probably comes from IMHO wrong assumption that the person who creates installer is somebody different from the person who creates application itself. My experience shows that usually application creator and setup package creator is the very same person (even in medium-sized corporations). So using the same technology for creating installer as for creating application is a huge benefit.
  4. Creators of main tools for developing software installers try to assume as little as possible about target systems. There are of course some benefits (you can create installer of almost every application, relatively small footprint) but there are also some drawbacks: you have to learn new philosophy of the software creation tool, you cannot use tools you are used to, you cannot use libraries you have written without some glue code, etc.

Taking into account above statements we can try to construct setup package with a completely different set of principles:

  1. Let Windows Installer do what it is good at. And leave the rest to another technologies (MFC, Java, .NET).
  2. Use as much of existing tools as possible and do not try to reinvent the wheel. If there are good UI designers on the market - make use of them instead of designing yet another one.
  3. Be developer friendly. That means:
    • Writing an installer should be as close to writing any other application as possible.
    • Details of the underlying technologies shouldn't be hidden from installer developer's view.
    • Wealth of extensibility points should be provided so that setup developers can achieve any functionality they want in their installers.
  4. Allow use of "heavy" frameworks like .NET or Java. After all if an application needs Java for proper operation then why not use it a few minutes earlier during installation time?

How does SharpSetup fit into that picture? Simply put, SharpSetup is a tool build around 4 principles stated above with specific focus on .NET applications. It uses Windows Installer XML (WiX) for developing core installation logic while leaving the GUI part for .NET/C#/WinForms/Visual Studio set of technologies.

How is SharpSetup installer built? What parts make up a complete installer and how do these parts fit together? Keep reading in the next posts.

 This article starts the series about basic SharpSetup concepts.

Next in series: SharpSetup installer structure