Search Tools Links Login

Setup & Deploy Your Application


Visual Basic 6, or VB Classic

Okay, so you've finished your application and are all set to distribute it to your clients, but do you know how? Are you aware of the issues and pitfalls you'll need to face while you design the setup for your application? Do you know about the right tools? This article discusses the basics of setup design, and will talk about several important issues that you should take care of when you write your setups.

Original Author: Cyrilgupta

Code

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



  1.    style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Copy
       all the files that your application needs to the target computer.

  2.    style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Give
       users access to some kind of icon so that he can click on it and run your
       app.

  3.    style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Provide
       users with a way to un-install your app (very important) if they later
       want to.

  4.    style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Perform
       all registry entries, file associations etc., which your application might
       need.


 


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.


 


Setup fundamentals


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
applications.


 


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.


 


Copying files


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
types.


 



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 WindowsSystem folder. This is just a matter of personal
taste.


 



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.


 


Shared Files


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
your doorstep.


 


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


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
Jstyle='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>


 


That's it!


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


 


style='mso-char-type:symbol;mso-symbol-font-family:Wingdings'>?¿style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'> Innosetup
ÔÇô My favorite setup maker, it's free, fast and efficient.

(Download: http://jrsoftware.org)


style='mso-char-type:symbol;mso-symbol-font-family:Wingdings'>?¿style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'> Visual
Studio Installer 1.1 ÔÇô Microsoft's installer. Not bad. This is free too.


(Download:
http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/download1.aspx)


 


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


Cyril@cyrilgupta.com

About this post

Posted: 2003-06-01
By: ArchiveBot
Viewed: 137 times

Categories

Visual Basic 6

Attachments

No attachments for this post


Loading Comments ...

Comments

No comments have been added for this post.

You must be logged in to make a comment.