Search This Blog


Sunday, August 10, 2008

Guidelines to Create an Installer for Windows Apps

After finish writing your software, it's time to distribute your applications to your customer. You think that software deployment should be easy, right? After all, all you have to do is to just fire up a Microsoft Setup and Deployment project and put in all the dlls in the application directory and you are done, easy?

But creating an installer package is not as simple as that, or else there is no need for Microsoft to put up a blog on Windows Installation. There is also no reason for the existence of InstallShield, Wise Installer, Advanced Installer. The proliferation of installers shows that creating a working, maintainable and extensible package for a commercial app with multiple dependencies is definitely not so straightforward.

However, for some unknown reason, there isn't much tips available on creating a working, maintainable and extensible installation package on the Internet. The aim of this post therefore, is to fill the gap. I am going to share some of my software packaging experience, and hopefully those who find that they need some packaging guidelines can find a few tips here.
Here they are:
  1. Choose a good installer authoring tool!
  2. Handle prerequisites correctly
  3. Setup the Application directory correctly
  4. Don't contaminate Windows system folder!
  5. Use Merge Modules
  6. Command Line
  7. 32 bit/ 64 bit issue
Choose a good installer authoring tool
Although Microsoft provides one with a free installer authoring tool, but it is not very useful. For one, whenever you want to add a new file into your application directory, you will have to add that file manually in the MS project. Thanks, Microsoft, that is just too much labor for a busy developer.
So you need a third party installer authoring tool. I chose Advanced Installer and suffice to say that it meets all of my need.
You may not like Advanced Installer, you may have other preferences. Or you want to choose your own tool instead of just following my choice. Whatever it is, your installer should have the following:
  1. Command line support!
  2. Application folder synchronization. This means that whatever changes you make to your application folder, the changes should be reflected into your packages.
  3. Scripting support! There will be a time when you find that your choice of installer can't do all your needs. You have to write scripts to do that particular actions, so scripting support is a must.
  4. Hides the nitty gritty details of product upgrades, product differentiation away from the users. Given two installer packages, how to tell whether the two are different packages or same package with different version numbers? A good installer should handle this for you.
  5. Intuitive UI
Handle prerequisites correctly
It works on my machine! Why it didn't work on yours? These are the usual developers response when they are confronted with low level, embarrassing bugs.

Most of the time, why the software doesn't work as expected is because the prerequisites are not properly installed. As a member of installation team, your task is to ensure that all the prerequisites are properly installed on client's machines. Or else face the consequence.

So, if you build your apps on top of the .Net framework, make sure that the .Net framework is packaged into your installer. Don't assume that the client's machines have it, even though it is pretty common. If you use any third party components, do make sure that you have the redistribution package. DON'T repackage the whole third party components into your installer. Your users will hate you for asking them to buy the third party component licenses, and your boss will hate you even more because you are driving away the sales.

Setup the Application Directory correctly
Application directory, or the program file directory is where all your exes and dlls are located... or not. Now, it may or may not be a good idea to put all your dlls into the application directory. If you are selling multiple apps to your customers and all these apps rely on a few base dlls, it makes sense for you to put these base dlls into the GAC or other common code repository, especially if these base dlls occupy a lot of disk spaces.

Deciding which dlls belong to the GAC or the application directory can be hard, though. One rule is that if the assembly is fundamental, rarely changed, and big, then you should put it in GAC. Or else, just put it in application directory.

Oh, what about the font files and the application data? Where should you put them? If the data is non-volatile, then you can put them in application directory. However, if the data changes due the life time of the application, then you shouldn't put it into the application directory; instead, you should put them in application data folder.

Don't contaminate Windows System Folder!
the system32 folder is a folder to store Windows related assemblies. Unless you are trying to hijack the OS, try to leave that folder alone.

There are 3 more tips that I will elaborate in the next post. Stay tuned.

Followup post: Guidelines to Create an Installer for Windows Apps (2)

No comments: