Setup & Deploy
your application: Writing A Good Setup For Your Application
So youíve finally managed to complete your latest
application after putting in a lot of last minute effort, spending sleepless
nights and consuming a million cups of Coffee. Pleased with yourself youíre
ready to lean back and relax. The grunt workís all done. Right? Wrong!
A veteran programmer wonít consider an application
complete until he has shipped it to the client and waited for 15 days. The
successful deployment of an application is just as tough if not any harder than
the actual coding of the application. I should know, Iíve made packaged
software that tens of thousands of users use each day. Iíve experienced a
seemingly endless variety of setup problems and provided solutions to them,
always after a valiant struggle. This article talks about that. Making setups
for your applications that your customers can run to install your app.
Letís act as if we are absolute beginner and canít tell a
mouse from the rodent that scurries about our kitchens.
What is a setup?
The job of the setup is to
all the files that your application needs to the target computer.
users access to some kind of icon so that he can click on it and run your
users with a way to un-install your app (very important) if they later
all registry entries, file associations etc., which your application might
Why do you need a setup?
For the pure and simple reason that in todayís development
environment thereís a very low chance that youíll ever make a useful app that
will work all by itself. Most applications need other files to function with,
like databases, runtime file, DLLs, etc. The setup is needed to make sure that
all the files/information that your application needs is in place and ready for
use. Also it is there to give the user an easy way to install your app on his
computer and make the software accessible to him when he needs it.
Before we start
This is a comprehensive tutorial, a big one. We are not
going to limit ourselves to any single setup program or issue, but instead try
to get a working grasp on the setup process itself.
More about MSM files
As applications grow bigger and use more and more
components, itís often impossible to keep track of all the runtime files and
registry entries needed to successfully install them on a PC. Microsoft
developed the MSM file format to solve this problem. An MSM file is a
collection of all files and registry entries needed to install a component in a
single file. Consider it like a zip file with registry information. Most of the
leading professional setup tools like Installshield, etc., have full support
for imports of MSM files into their setup. Microsoftís tool Visual Studio
Installer too supports MSM files. The runtime installations of almost all major
Microsoft technologies are now available in the merge module format that you
can just drop into your project to install.
Letís explore the basic philosophy behind setup in a little
more detail. The task of the setup is to perform all tasks and actions
necessary to ensure that your software runs correctly. For most software this
means copying files, performing registry entries and creating an icon that the
user can click to run your application. If something unexpected happens and
your setup fails, then you have to make sure that you undo all the changes that
you made to the userís PC. Your setup should also create an un-installer to
remove all files and registry entries that you may have made on the computer.
Making the setup
To illustrate the different steps involved in designing a
setup, letís make the setup for an imaginary application called Fooapp. Weíll
go through the different steps of making the setup for Fooapp and at the same
time we will also learn about a number of different problems that you as a
setup maker will need to overcome.
Identify the Dependencies
First we have to figure out what files to package with
Fooapp. Letís suppose that weíre using a database to store the addresses of
FooCustomers through FooApp, and we also have a set of pictures that we need to
load in FooApp. Our application depends on these files to run (thus
Ďdependenciesí). Our setup should copy these files to the correct folder so
that our application can access them when it runs.
We can call these files the first level dependencies:
Files that are unique to your software and are absolutely necessary. These
files are usually copied within the folder where you copy the mail executable
for the application (APPDIR).
In these days of distributed development itís hardly
possible that you will be able to make an app without using any components.
These components may include ActiveX controls, DLL files, .Net assemblies, etc.
These files form the second level dependencies for your setup project. These
files are necessary for your application but may be Ďsharedí by other
There are many strategies to identify the dependencies for
your project. You can use a tool like Depends.exe that ships with Visual Studio
to identify dependencies on DLLs. If your application is made using Visual
Basic then you can use the ĎPackage and deployment wizardí to generate a list
of dependencies for you. Sometimes you will have to use your experience to
identify the technologies you have used and the files you need to run it. This
is especially true when you use a lot of third party components that may in
turn use other components themselves.
A good way to make sure that you have all dependencies is
to keep installing your application on a Ďcleaní installation of Windows. This
way you will be able to identify each and every file that your application
needs to run.
Once youíve identified all dependencies youíre ready to
copy them to the target PC. You should know where to drop each file so that
your application can use them. Hereís a quick categorization of some basic
Your application files Ė Your main executable file and all data files
associated with it should be copied to the application directory. Although itís
quite possible to install to and use the data from any directory on the PC,
itís recommended that you restrict your files to the application directory
only. These files may include your database files, pictures, etc.
C/C++ Style DLLs Ė The old c/c++ style DLLs have to be referenced by path. When
you reference such a DLL (like when calling a Windows API function) Windows
will first look in your application directory, and then in the Windows System
directory for that DLL. If it canít find the DLL you will get an error. If
youíre using one of these DLLs in your project and itís unique to it then you
should copy it to your application folder (the directory where you copy the
main executable). If youíre using a DLL that is used by many applications then
you can copy it to the Windows\System folder. This is just a matter of personal
ActiveX DLLs and OCX files Ė Before your application can use the ActiveX DLLs
and custom controls, information about them has to be entered in the Windows
Registry. This information includes the Globally Unique Identifier(GUID) for
the component, and the path where it resides. By convention ActiveX DLLs and
OCX files are always copied to the Windows System folder. Although itís
possible to use an ActiveX file in any other directory too, itís recommended
that you copy only to the Windows System folder.
Registering ActiveX controls
As I told you in the earlier section, any ActiveX file
that you use has to be entered in the Windows registry before your application
can use it. Microsoft provides a free tool to add this information to registry
and most setup programs too use it. The tool is Ďregsvr32.exeí, it can be found
in your Windows system directory.
Most setup programs allow you to mark a file for
registration. There might be flags like Ďregserverí (in InnoSetup) or you may
be able to select an attribute that will allow you to mark a file for
registration. Make sure that you test each file before you mark it for
registration in the Windows registry if you mark an invalid file your setup
will show an error, and sometimes it may even crash.
To test whether a file is valid or not, run the following
command on it Ė Ďregsever32 filename.í The file may have to be copied to the
Windows System directory before you can do it.
The concept of ĎShared filesí is very important and Iíve
found that many first time setup makers who neglect this end up earning the
wrath of their users afterwards.
In todayís development scenario almost every programmer
makes the use of third party activex components and DLLs. In a common situation
many applications installed on a computer will use the same components to run.
If during the un-installation process your application deletes these Ďshared
filesí or changes them in any way then those other applications will not run.
As a responsible setup maker itís your job to ensure that your application
installs and uninstalls without wrecking any other application on the userís
computer, so you have to take great care that you do not delete any shared file
from the userís PC.
How to identify whether a file is shared?
The thumb rule is: if itís not unique to your app, itís
shared. The shared files will include all activex DLLs and OCX controls not
developed by you exclusively for this application (like the tab control, or the
chart control), all DLLs that are a part of any standard library (like
MSVCRT.DLL, or MSVBVM60.DLL, etc). If your setup deletes any of these files
during un-installation, you should prepare to welcome a very angry customer at
Overwriting Used Files
Often you will need to replace the older version of a DLL
with a new version. You can do this without a problem if your DLL file is not
in use by any other application, however if itís being used by any other app and
you try to overwrite it, your setup will crash! Some system DLLs are
perpetually in use and canít be overwritten at all when Windows is running. To
overwrite these files you need to reboot Windows and overwrite them before
Windows loads completely. Most setup making programs allow you to mark such
files for Ďreboot before overwriting.í Take care that you identify and mark
these files correctly or your setup will never run to the end.
The most common files that need re-start for overwriting
are Ė OLEAUT32.DLL and OLEPRO32.DLL. These files are used by virtually every
Windows based applications and canít be over-written without re-starting. You
should identify the other files manually.
To manually identify such files Ė load as many
applications as you can, and then try copying each file in your application to
its target location manually using Windows Explorer. If you can successfully
copy it then the file does not need rebooting. If you canít, then better mark
this file for rebooting.
Creating icons for your application
After youíve finished copying all the files needed to run
your program you should create the icons through which your users may run the
application you made. If you use a setup making program like Innosetup, or
Installshield, you will be able to specify an icon file and the file to which
the icon will point. Itís recommended that you create an icon for your main
executable, the help file and also for your companyís webpage.
You may also create an icon on the userís desktop and on
the quick launch bar if you think your application will be used very often. Do
make sure however to ask the user before you create an icon on the desktop or
the quick launch bar. Itís bad manners not to.
Un-installation is just as important as installation for any
setup. Most new setup making programs create an un-installer automatically that
the user can run from the ĎAdd/Remove Programsí section of the Windows control
panel. Make sure that you do not remove any vital file that can effect other applications
during un-installation (look up the section on shared files above.) However,
most of the time this will be transparent to you and will not require any work
from your side, so relax J
Yep, thatís the setup making process in a gist, and all the
important precautions have been outlined for you. Your skills will grow from
setup to setup though, so get right to it and have fun!
Do not forget to test your setup a lot. The best thing to do
is to install on a clean installation of Windows, and then also on a very-used
computer. Your app should install and work on both,
Some free Setup making utilities
Ė My favorite setup maker, itís free, fast and efficient.
Studio Installer 1.1 Ė Microsoftís installer. Not bad. This is free too.
Innosetup has a huge community of developers who absolutely
love it because of what it can do. Itís one of the fastest installers on the
net, itís absolutely free and it can do everything that a professional setup
application like Installshield can do (without the fancy bells and whistles
though.) However, thereís one important feature that Innosetup doesnít have.
Support for Microsoft Merge Modules (.MSM files), thatís where the Microsoft
visual studio installer comes in.
Innosetup also has scripting capabilities and is perfect for
power programmers who need to make their setups as flexible as they can. The
only feature that InnoSetup lacks is support for imaged during installation and
for MSM files. Using Innosetup requires some coding skills and youíll need to
spend some time studying it.
You should use the Microsoftís Visual Studio Installer
wherever you canít use Innosetup. This will mostly include situations in which
you canít find an alternative to using MSM files (Installer Microsoft Speech
API 5 for example, the runtimes are only available in MSM format.) Be warned
though, Visual Studio setups are slow and klunky. They just canít compare with
the blazing speed or ease of use of setups made using Innosetup.
By Cyril M Gupta