Visual Installer
This column appeared in the January 2000 edition of
EXE. It discusses the Windows Installer technology, with particular reference
to the new Visual Installer tool which Microsoft have released for inclusion
into the latest version of Visual Studio.
Last month I mentioned that the next version of Visual Studio
was some way off yet. However this doesn’t mean that Microsoft aren’t
providing any new tools for Visual Basic developers. Far from it. The Visual
Studio 6.0 Plus Pack CD was made available to MSDN subscribers in the October
1999 quarterly update (Office Test Platform and Development Tools Disk 15:
Windows 2000 Developer Readiness Kit). This toolkit goes some way towards
updating the Visual Studio product with some of the newer technologies. The two
most significant technologies are the Microsoft Data Engine (which I covered in
the November 1999 issue of EXE), and the new Visual Studio Installer 1.0
product which provides a means of creating installation programs that work with
the relatively new Windows Installer technology.
Before we get into the Visual Installer product, which is the
key topic in this months column, I’d just like to review some of the other
items available on the CD. Microsoft are pushing Windows 2000 very hard, as is
indicated by the fact that they’ve already announced the impending
retirement of the NT4 version of the MCSE exams! For developers who
haven’t had much of a chance to read up on the new features within Windows
2000 this CD provides some good starter material. There are several
presentations lifted from last years TechEd 99 conference which discuss
features such as MSDE, COM+, and the Windows 2000 Application Specification.
There are also some selected chapters from a Microsoft course entitled Building
Solutions for Microsoft Windows 2000 with Visual Basic, as well as the Visual
C++ equivalent. Finally there are also several whitepapers that discuss Active
Directory and the Windows Scripting Host.
Windows Installer
The Windows Installer was the subject of a feature article by
Ian Murphy in the July 1999 edition of EXE, although if you don’t have a
copy of that particular issue it can be found on the EXE Online site. For this
reason I will not attempt to provide too much coverage of this underlying
layer, but there are a few aspects that I will discuss first before preceding
further in order to add to the information that Ian originally provided.
Firstly the Windows Installer 1.0 was made available for the first time with
Microsoft Office 2000, but a newer version 1.1 ships as an integral part of
Windows 2000. The second point is that the whole Windows Installer technology
is itself a redistributable component that can be added to Windows 9x or
Windows NT 4. The redistributables, both version 1.0 and version 1.1, for the
Windows 9x and Windows NT 4 are available as part of the platform SDK that
ships with MSDN.
One feature likely to be popular with members of installation
teams is that the Windows Installer is transactional. This means that a full
regression path is maintained throughout the installation so that in the event
of a failure the state of the system can be restored. It is only at the point
after the installation is confirmed as having completed successfully that the
rollback data is wiped. A further feature, of interest to both installers and
developers alike, is that Microsoft are now providing direct support for
different levels of application patching, ranging from full file replacements
down to modifying binaries at the byte level. True to their greater focus on
providing for the enterprise environment, the Windows Installer can support
environments from a local CD–based installation through to network
installation servers.
The way in which the Windows Installer runs differs among the
two general categories of platform: under Windows 9x it is available as a
callable COM routine, whereas under Windows NT 4 and Windows 2000 it runs as a
true service. By the way, if it is being installed onto Windows NT 4 there is a
prerequisite requirement that the enhanced shell that is provided by Internet
Explorer 4.01 SP1 or higher must already have been installed.
One of the features most visible to the end user is of course
the auto–repair facility and it is because of this that the slightly
revised Windows shell is required. You will be aware that the applications that
are shown under the Programs menu from the Start button are normally
straightforward shortcuts. For example if you find the Notepad menu item (under
Accessories), right click it, and select Properties you will see that the
target location is set to
%SystemRoot%\system32\notepad.exe. However
if you have Office 2000 installed then a right–click over one of the
application icons will reveal that no such shortcut information apparently
exists. In fact what is happening here is that the target reference is actually
a GUID, therefore it isn’t actually displayed because there’s not
much that a user will want to do with it. When the user clicks the shortcut
this GUID is passed to the Windows Installer with a request for the component
path. The Windows Installer will then check that the file and its dependencies
actually exist; if not then it is the Windows Installer itself that invokes the
repair utility. Once this has been successfully completed the required
component path is returned back to the Windows shell and the application is
launched.
Visual Studio Installer
Windows developers who chiefly use Visual Basic as their
development tool will be only too aware that they never really get the
opportunity to use the full Visual Studio environment. That’s changed now
because the Visual Studio installer project environment is now hosted within
Visual Studio. The New Project dialog allows for three such project types (see
figure 1), one of which is specifically geared towards Visual Basic.
Figure 1: New installer type projects within Visual
Studio
The Wizard that is displayed by the Visual Studio Installer
(VSI) project is notably more concise than the Package and Deployment Wizard
(PDW). Whereas the PDW asks you the questions up front and then generates the
project for you, the VSI purely asks which Visual Basic project file (.vbp) to
work with and then sets up a new VSI project file (with the extension .wip for
Windows Installer Project) using default values. You then have the opportunity
to alter the various settings interactively which makes the whole process much
better than before. The Project Explorer window groups the various
configuration data into four Target Machine categories and a separate Files
listing. The Target Machine categories are:
-
File System: where the various files get
installed to. The files shown here only relate to non–redistributable
components; the standard Microsoft items such as the Visual Basic runtime and
the common controls are bundled up separately into items called Merge Modules
(with the extension .msm) and do not get displayed. These days Microsoft makes
more of a thing about specific common installation locations such as
Application Folder, User’s Desktop, User’s Start Menu, and Windows
System Folder, all of which are displayed by default. Other less frequently
chosen locations such as the Common Files Folder can be added from a selection
displayed by right clicking the folder pane and selecting Add Special Folder.
-
User Interface:
allows you to specify which dialogs will be displayed. A standard
list of choices is initially presented but you can add additional
dialogs by right clicking the User Interface pane and selecting
Add Dialog. Users of InstallShield might find this description
similar, but the difference here is that you can’t see
a preview of the dialog at development time. There is scope
for adding your own graphic to each dialog via the BannerBitmap
property. The bitmap here must be a long narrow item that fits
along the top of the dialog, but curiously I couldn’t find
a reference anywhere within the documentation as to what size
is necessary for an exact fit: my own deduced values were 497
pixels wide by 68 pixels high.
-
Registry: almost identical in appearance to
RegEdit, allows you to specify new registry entries. As with other items it is
possible to specify whether or not this information should be deleted in the
event of an uninstall.
-
Associations: allow you to associate
different types of Windows objects with your application. Apart from the
typical document extensions, this also provides association support for MIME
types, COM objects, and type libraries.
The Files node of the Project Explorer displays the core
application executable, plus all dependent files whether they be common
controls and runtime files, or your own additions such as help files. Selecting
each file causes the Properties window to display default settings which, in
most cases, you can alter should you wish to. For example, a Vital property
determines that if a file can’t be installed for some reason then the
whole installation is kaput and should be rolled back. There are also settings
to denote whether a file should be read–only, whether it is a shared or
system file, and whether (and how) it should be registered. You can also
specify that a file be regarded as permanent, that is that the file will still
exist if the product itself is subsequently uninstalled.
Conditions
Another feature that is new from previous versions of
Microsoft setup tools is that simple expression macros can be processed at
runtime in order to determine whether to take a course of action, and this can
be applied at both the global level and at the individual file level. A
condition consists of a simple statement that evaluates to true or false and
which can be made against any one of many predefined property values. For
example there are a couple of properties called Version9X and VersionNT which
return the major and minor version numbers of the current version of Windows;
on any given machine only one of these will actually return a value so if the
target machine is Windows NT 4 then the Version9X property will return an empty
string. This could be very useful if you want to install target platform
specific files. For example if you create two versions of a component that are
closely aligned to the underlying services provided by the operating system,
for example networking, you can bundle both files into the install project but
when the condition expressions are evaluated only one will equate to true and
so only one instance of the file will be installed. An example of a simple
condition is
VersionNT>=400
Properties Dialog
The Properties dialog under the Project menu also provides a
greater than expected set of customisation. A Launch Condition tab allows you
to specify one or more conditions which will be evaluated when the installation
program starts up. For each launch condition you can also specify an error
string to be displayed in the event that the condition fails.
The Build tab contains one feature you may want to use until
Windows 2000 (or Office 2000) becomes more widespread. A Build Type list box
offers by default an Installer type build, but examination of the alternate
entries reveals the important option called Installer With Visual Windows
Installer Loader. The purpose of this build option is to include the Windows
Installer component/service along with your own installation, so if it
doesn’t already exist on the target machine it will be installed first.
There’s no doubt that the Visual Installer is a
significant improvement over the Package and Deployment Wizard. It’s no
surprise then that companies that specialise in installation tools, such as
Wise and InstallShield, lost no time in establishing themselves as alternate
suppliers of installation products based around the Windows Installer. As
Visual Installer doesn’t offer much in the way of scripting there is still
a place for alternate tools of this nature, but I’d also guess that there
will probably be a few less developers who feel the need to go out and pay for
something which is a replacement for something that is free to registered
users.
