MSI (Package File)
This is the file that contains the instructions for
MSIEXEC.EXE to install the application. The MSI file is a Database file format.
The .msi file in a package is a COM structured storage file. That is, it can
contain multiple streams of information. These streams can include the
following:
- An Installer database
- A summary information stream
- .cab files containing components to install
- Source files for the installation
- Transforms
Operating systems and Windows Installer Versions
Release
|
Version
|
Description
|
Windows Installer 2.0
|
2.0.2600.0
|
Released with Windows XP.
|
Windows Installer 2.0
|
2.0.2600.1
|
Released with Windows 2000 Server with Service Pack 3 (SP3).
|
Windows Installer 2.0
|
2.0.2600.1183
|
Released with Windows 2000 Server with Service Pack 4 (SP4).
|
Windows Installer 2.0
|
2.0.2600.2
|
Released as a redistributable.
|
Windows Installer 2.0
|
2.0.2600.1106
|
Released with Windows XP with Service Pack 1 (SP1).
|
Windows Installer 2.0
|
2.0.3790.0
|
Released with Windows Server 2003.
|
Windows Installer 3.0
|
3.0.3790.2180
|
Released with Windows XP with Service Pack 2 (SP2). Released
as a redistributable.
|
Windows Installer 3.1
|
3.1.4000.1823
|
Released as a redistributable. This version is has the same
functionality as version 3.1.4000.2435.
|
Windows Installer 3.1
|
3.1.4000.1830
|
|
Windows Installer 3.1
|
3.1.4000.3959
|
Released with Windows Server 2003 with Service Pack 2 (SP2).
|
Windows Installer 3.1
|
3.1.4000.2435
|
|
Windows Installer 3.1
|
3.1.4001.5512
|
Released with Windows XP with Service Pack 3 (SP3).
|
Windows Installer 4.0
|
4.0.6000.16386
|
Released with Windows Vista.
|
Windows Installer 4.0
|
4.0.6001.18000
|
Released with Windows Vista with Service Pack 1 (SP1) and
Windows Server 2008.
|
Windows Installer 4.5
|
4.5.6002.18005
|
Released with Windows Vista with Service Pack 2 (SP2) and Windows
Server 2008 with Service Pack (SP2.)
|
Windows Installer 4.5
|
4.5.6000.20817
|
Released as a redistributable for Windows Vista.
|
Windows Installer 4.5
|
4.5.6001.22162
|
Released as a redistributable for Windows Server 2008 and
Windows Vista with SP1.
|
Windows Installer 4.5
|
4.5.6001.22159
|
Released as a redistributable for Windows XP with Service
Pack 2 (SP2) and later, and Windows Server 2003 with SP1 and later.
|
Windows Installer 5.0
|
5.0.7600.16385 or greater
|
Released with Windows Server 2008 R2 and later and
Windows 7 and later.
|
What is a Component?
A component is a piece of the
application or product to be installed. They are the fundamental unit that
defines the functionality of the software application. Examples of components include single files,
a group of related files, COM objects, registry keys, INI file settings,
shortcuts, resources, libraries grouped into a directory. The following list
provides a summary of information about Component structure and attributes:
- File resources: Components can contain file resources. If a file resource is the key path to the Component, it is known as the key file. If a file is not the key path, it is known as a companion file. There is no practical limit on the number of files or file types that can be in a Component. There are, however, rules about Component structure that define when certain types of files should have an entirely dedicated Component.
- Registry resources: Registry resources are registry keys that are required by the Component.
- Shortcut resources (entry point): Shortcuts are defined within a Component and must point to a file within the Component. Shortcuts can be advertised (entry points) or standard Windows shortcuts.
- Document extension mappings and MIME types (entry points): Document extensions and MIME types are configured at the Component level and point to a file within the Component.
- Additional resources and attributes: Components can have many resources and configuration items associated with them. Some of these include:
- Controlling and installing services
- Making INI file entries
- Creating directories
- Setting environment variables
- Configuring ODBC
Some new attributes that are
specific to Windows Installer can also be a part of a Component, including
entry points, key paths, and Component Codes.
Identifying components
A component is identified by its
Component Code which is unique. Although a Component can contain these items,
it is not required to contain all of them. The installer service installs or
removes a component as a single coherent piece. It tracks every component by
the respective Component GUID specified in the ComponentId column of the
Component table. Two components that share the same component ID are treated as
multiple instances of the same component regardless of their actual content.
Only a single instance of any component is installed on a user's computer.
Several features or applications may therefore share some components.
What are Reference Counts?
Components are also reference
counted to prevent uninstallation when more than one application is using a
shared piece of software. Reference counts were introduced with Windows 95. All
installation programs that follow Microsoft’s installation guidelines increment
a counter in the registry whenever a DLL is installed to a shared location,
such as the system directory. For example, if four applications had installed
abc.dll to the System32 directory, that DLL would have a reference count of 4 in
the registry. If one of the applications is uninstalled, the uninstall program
would simply change the reference count to 3 and leave the file in place
because other applications are obviously using the DLL. If the reference count
for a file is 1, the uninstall program is free to remove the file because it
can assume that the program being uninstalled is the only program using the
file. Occasionally, uninstall programs will break other software because they
remove shared registry keys required for a DLL to work properly. Windows
Installer improves on reference counts by putting them at the Component level.
Because a Component contains all the various system resources required for a
DLL to operate properly, these related resources will remain on the system if
other software is still using the DLL. When a user selects a feature for
installation, the installer determines which components must be installed to
provide that feature.
What are entry points?
A very important attribute of a
Component are the Entry Points. These allow Windows Installer to proxy the
startup of an application and perform application management tasks before the
user is allowed to access the application. In other words, when you
double-click the icon for a Windows Installer packaged software application, it
does not actually attempt to start the application directly. The icon is a
special icon that asks Windows Installer to find the software application and
start it. This is when Windows Installer can use the MSI repository
information, the installed application resources (files, registry keys, and so
on), and the original package file to perform the magic of self-healing and
install on demand. An entry point turns into an advertised interface when any
Feature that its Component belongs to is advertised or installed on a target
computer system. When a Windows Installer package is advertised, advertised
interfaces make it appear as though the application is installed and ready to
use. When a Windows Installer package is installed, advertised interfaces
trigger Windows Installer for self-healing and user profile fix-up checking. An
entry point/advertised interface can be:
•A shortcut (special Windows Installer shortcut)
•A document extension (association)
•A MIME type (Internet document types)
•A Class ID (CLSID)—Programmatic identities used for sharing
software within and between various applications
How do Components work?
Through the concept of a
Component, Windows Installer uses metadata to model a functional unit of the
application software it is describing. This Component definition is placed in
the repository of any machine on to which it is installed. However, if the
Component becomes broken, how does Windows Installer tell that the Component is
not installed as defined in the repository? For each Component that is
installed on a computer, Windows Installer checks the existence of a specially
tagged resource known as a key path within the Component to determine whether
the Component is healthy or in need of repair. If this tagged resource is
missing, the entire Component is re-installed. A key path can be a directory, a
file, a registry key, or an ODBC data source. The reason that Microsoft Word
still works when winword.exe is deleted is because winword.exe is the key path
of a Windows Installer Component. When a user attempts to use Microsoft Word,
Windows Installer checks to see that the key path of this Component
(winword.exe) exists. If it does not exist, self-healing would be invoked to
fix the problem. Among the uses of a key path, three are very relevant to
administrators:
- Self-healing detection
- Advertising/Install-on-Demand detection
- User profile fix-up detection
What are Qualified Components?
A qualified component is a method
of single-level indirection, similar to a pointer. The easiest way to
understand qualified components is to consider some of the problems of
localized software. Suppose you’ve created a program that uses a file named
tips.txt to hold “tip of the day” information that the user can choose to
display. Being a developer of software for the global market, you’ve had
tips.txt translated into five different languages. And being a good user of the
Windows Installer, you’ve chosen to advertise this component, rather than
install it, so that it doesn’t take up disk space unless the user chooses to
view tips. Now, think about the code within your product at the time when the
user chooses to turn on the tips and you need to install the advertised file.
The Windows Installer provides an API call named MsiProvideComponent that,
given a component code (the GUID for a component), will install that component.
If this was your only choice for installing components, the logic of your code
might look like this (this is pseudo code, not actual Visual Basic
code):
If Language = English Then
Call MsiProvideComponent
(EnglishGUID)
ElseIf Language = French Then
Call MsiProvideComponent
(FrenchGUID)
ElseIf Language = German Then
Call MsiProvideComponent
(GermanGUID)
ElseIf Language = Japanese Then
Call MsiProvideComponent
(JapaneseGUID)
ElseIf Language = Spanish Then
Call MsiProviderComponent
(SpanishGUID)
Code based on this pseudo code
would get the job done, but there’s a better alternative, and that’s where
qualified components come in. The Windows Installer provides another API call
named MsiProvideQualifiedComponent. This API call takes a component category
code (another GUID) and a text qualifier and uses them to find the actual
component to install. Using MsiProvideQualifiedComponent would reduce the
pseudo code to the following line:
Call MsiProvideQualifiedComponent
(CategoryGUID, Language)
