Search This Blog


Tuesday, August 26, 2008

Guidelines to Create an Installer for Windows Apps (2)

This is a continuation of the post Guidelines to Create an Installer for Windows Apps.

In this post, I will elaborate on the 3 points that are not elaborated before:

  1. Use Merge Modules
  2. Command Line
  3. 32 bit/ 64 bit issue

Use Merge Modules
Merge modules provide a standard method by which developers deliver shared Windows Installer components and setup logic to their applications. They are like methods and classes in programming. Merge modules become important when you need to share setup components among different applications or when you are upgrading your third party components in batch.

It is common for applications to depend on third party packages to deliver underlying framework functionalities or UI components. The distribution of these software packages can be difficult because you are not the one who write them and thus may not be very familiar with them. If you have to package those third party files separately, you will have to take care of all the dependencies and be very careful in making sure that no file gets left behind. This is a maintenance headache.

Merge modules become even more important if you have a family of products that share some of the basic components. Grouping similar, common application files together will make deployment a much more pleasant experience.

Command Line Support
Do not get an author installing tool that doesn't have command line support! Command line support helps you to automate your packaging tasks. Without command line support, there is no way you can create reliable daily builds.

You may think that your application is small, or that your setup packages don't need a lot of fanciful features. But the fact is that there is no way to create a professional package without using command line tools. For starters, if you have daily build-- if you don't, stop reading this article and set it up now! ( If you need help you can contact me, my consultation is available)-- you should include software packaging into the build. That needs command line.

You need to stamp your product version on the installer package, that needs command line.

You need to synchronize the package version and the application version, that needs command line.

If you allow your users to install different versions of an application on a computer, you will need command line tools to:
  1. Set the name of the shortcut icon. Make sure that it is tie to the package version.
  2. Set the name of the application folder. Make sure that it is also tie to the package version.
If your installer tool doesn't support command line, drop it now! Get one which has command line support, such as Advanced Installer.

Disclaimer: No, I am not affiliated with Advanced Installer; I am just a happy user. You may seek my consultation if you want to package your applications using Advanced Installer.

32 bit/ 64 bit issue
This may not be a critical issue if you don't plan to support 64 bit OS. But as 64 bit OS is going mainstream-- I don't know when, but I am pretty sure that it will supplant 32 bit OS one day, just like how 32 bit OS supplanted 16 bit OS-- you may want to get a headstart.

Catering for two platforms can be difficult. You may need to know what to install on which platform, how to take care of merge module dependencies and things like that.  Having a good tool can solve some of the problems, but not all.

No comments: