Before Windows Installer there was no specific Windows functionality supplied to install products. (Strictly speaking, there has always been the Setup API, but its main functionality is based on using INF files to perform installations.) The Windows programming environment happened to be rich enough that developers could use its APIs to perform installs. A major consequence of using the general-purpose Windows APIs was that there was no consistent integration between Windows and the installed product. For example, if you wanted to inventory the products installed on a system, you could enumerate the contents of the Registry area used by the Add/Remove Programs applet, but any number of different tools could have installed each product, and even a simple task such as finding where the product was installed was nontrivial.
Around the Windows 2000 timeframe, Microsoft supplied Windows Installer as the installation technology for Microsoft Office 2000. Windows Installer provides a standard way to install, maintain, and uninstall software.
Transactional Behavior
Nobody wants an installation to get partially completed and then fail for some reason, leaving a system in some indeterminate state. Windows Installer turns product installations into an all-or-nothing proposition—the product is either successfully installed on the system, or the installation does not work and all the changes that might have been made to the system are backed out.
A large part of this transactional nature is a consequence of eliminating as much code as possible from the installation process. Windows Installer offers features that mean you don't necessarily need to run custom code at install time. This is necessary because otherwise you, the installation developer, would be responsible for reversing any changes made to the system during the installation.
As an example, consider COM server registration. A COM server historically required its DllRegisterServer function to be called, and likewise the uninstall process would call DllUnregisterServer. This requires the COM server to initialize, where it might need a dependent DLL that isn't on the system yet. Windows Installer deals with this by storing COM registration data inside the actual installer package, the MSI file, so it doesn't need to call or run the COM server to install or uninstall the Registry entries. Windows Installer can add or remove the COM Registry entries whether the COM server itself is functional or not. Installing the COM server means copying the file to the system and writing the Registry entries from installer tables.
The same general idea applies to Windows Services (sometimes called NT Services). When they are installed with something like a –Service command-line argument to a run of the Service program itself, install and uninstall are dependent on the Service being functional. However, Windows Installer has support for installing Services directly from the installation package with no requirement to run the Service executable to install it. Consequently, installation and removal of the Service are controlled more safely.
Repair
It's not unusual for files that belong to a product to get accidentally deleted. Windows Installer has repair features that restore an application that is broken because of missing files or Registry entries. If the installation marks a file or a Registry entry as "key," Windows Installer has the capability to restore the file or entry automatically if it's missing. When you go to Add/Remove Programs, a Repair choice is offered, along with other choices to uninstall or modify the installed features.
Repair is probably the feature that most often surprises developers. They are generally familiar with the idea that a product can be installed and then manipulated afterwards by adding new files or removing unwanted ones, only to find that the repair mechanism restores the files or Registry keys to the initial installation state. Users too are sometimes surprised when they remove a shortcut and move it to some other location, only to find that Windows Installer restores it through a repair.
64-bit
There is support in Windows Installer for installing applications onto 64-bit Windows operating systems. This doesn't just mean that you can install 32-bit applications onto 64-bit systems, it means that Windows Installer is likely to be the only way to install 64-bit applications onto a 64-bit system.
Sharing Files
Sharing has always been an important aspect of installations. The sharing issues are largely responsible for the situation popularly (or unpopularly) known as "DLL Hell." You need to work out which Microsoft DLLs need installing to support your product, and consequently run the risk of creating an incompatible set of system DLLs. Or you might have shared components in your company's products that all need to be installed and managed correctly on client systems. This is becoming less of an issue since Windows 2000 introduced Windows Protected Files, a feature that prevents installations from replacing critical system files. Windows Installer does not even attempt to replace those protected files that are considered to be part of the OS.
Sharing in Windows Installer uses reference counts for each unique component. You still need to follow rules, as you'll see later, but the Windows Installer component sharing mechanism is much more robust than previous schemes.
System Integration
Products installed with Windows Installer are integrated into Windows. APIs and COM objects can report information about installed products to a detailed level. In addition, a Windows Management Instrumentation (WMI) provider reports the content and configuration of installed products. If you ever wondered whether there is a way to discover accurately what products are installed on a system, the fact that there are standard API calls is a vast improvement compared to prowling the Registry looking for products. These APIs not only return detail about potentially every file installed by a product, they also allow the application code itself to integrate with the installation and modify installed components on the fly. The APIs also allow access to installation packages (MSI files). For example, it's relatively easy to query the contents of an installation package and compare the contents with a version of that package that is installed on the system.
.NET
Windows Installer has built-in support for installing .NET assemblies into the Global Assembly Cache (GAC). This is likely to be the only way you should install assemblies into the GAC. Yes, Microsoft supplies the Gacutil.exe utility in the development environment, but this program knows nothing about the Windows Installer reference-counting scheme, so shared assemblies installed into the GAC require Windows Installer to maintain correct shared-installer reference counts.
For the System or for Current User
When you start installing a product you are often asked if it's being installed for you (private to your account on the system), or whether it's being installed for everyone. These generally affect whether, for example, certain Registry entries are written to the HKEY_CURRENT_USER (HKCU area) or to HKEY_LOCAL_MACHINE (HKLM). If you assume that the target user is in fact the current user of the system, this means that the application should not be visible to other users. But think about the mechanics of COM registration, where code in the DllRegisterServer entry point creates COM registration entries on the system. You'll realize that there is no way that the code in DllRegisterServer knows whether the installation is per-user or per-machine, so the registration code cannot know which Registry location is the correct one, HKLM or HKCU. The code in DllRegisterServer registers to the local machine Registry keys, so in effect an install for the current user leaves COM servers accessible to everyone on the system. It therefore makes a lot of sense to get COM servers out of the business of self-registration and have Windows Installer create the registration entries in the appropriate Registry location.
Security of Installation vs. Security of Product
When trying to install a product for a user who might not have the security privileges to install the product, there needs to be a way for this user to install the product without requiring those elevated privileges on a permanent basis. Windows Installer provides some ways to deal with these issues. One reason it helps with these issues is because it runs as a Windows Service and doesn't need to be constrained by the privileges of the current user. Another reason is because policies can be configured so you can perform an installation with elevated privileges on behalf of a user who is not privileged.
Updating and Deploying New Versions
Before Windows Installer, when you wanted to ship corrections to a product, perhaps you simply rebuilt the entire installation setup and sent it to your clients. However, you can't just ask your client to install the product, because you'd end up with two copies of the product on the system. However, if you're supplying a fix or an update you need to replace the existing installed product. Generally speaking, the incoming new installation would detect the existing one and uninstall it, or perhaps even arrange to completely install itself on top of the existing product. Another choice would be to produce a service pack to update the product, often requiring use of a separate tool to install the updates to the client system. To summarize, there have been a number of ways to deal with these maintenance issues. Windows Installer has some formal mechanisms for installing product updates and fixes.
Advertisement
You can think of advertisement as installation-on-demand. It can be particularly useful in corporate environments—you can have practically everything installed (shortcuts, Registry entries, and so on) except for the files. When you reference the advertised product, the installation starts installing the files from a network location onto the client system. Even after a product has been installed, perhaps some of its features will be advertised, so that when the advertised feature is first used this feature is installed.
The idea of advertised features is that you install a hook of some kind, typically a shortcut. Using this shortcut causes the feature to be installed. If the advertised feature consists of one or more COM components, there is a similar advertisement installation step that causes the component to be installed.
Running Your Own Code
Many of the observations made might give the impression that you can't add your own code to the installation process. In fact you can—when you do this it's called a custom action. Many types of custom actions allow you to run VBScript, executables, and call into a DLL, to quote a few examples. So that changes to the system can be provided with transactional behavior in mind, you can associate these custom actions with the install, the uninstall, and also the rollback process that occurs when an installation fails and everything done to the system is being undone to restore the system to its original state.
Source of Information : Apress The Definitive Guide to Windows Installer
Around the Windows 2000 timeframe, Microsoft supplied Windows Installer as the installation technology for Microsoft Office 2000. Windows Installer provides a standard way to install, maintain, and uninstall software.
Transactional Behavior
Nobody wants an installation to get partially completed and then fail for some reason, leaving a system in some indeterminate state. Windows Installer turns product installations into an all-or-nothing proposition—the product is either successfully installed on the system, or the installation does not work and all the changes that might have been made to the system are backed out.
A large part of this transactional nature is a consequence of eliminating as much code as possible from the installation process. Windows Installer offers features that mean you don't necessarily need to run custom code at install time. This is necessary because otherwise you, the installation developer, would be responsible for reversing any changes made to the system during the installation.
As an example, consider COM server registration. A COM server historically required its DllRegisterServer function to be called, and likewise the uninstall process would call DllUnregisterServer. This requires the COM server to initialize, where it might need a dependent DLL that isn't on the system yet. Windows Installer deals with this by storing COM registration data inside the actual installer package, the MSI file, so it doesn't need to call or run the COM server to install or uninstall the Registry entries. Windows Installer can add or remove the COM Registry entries whether the COM server itself is functional or not. Installing the COM server means copying the file to the system and writing the Registry entries from installer tables.
The same general idea applies to Windows Services (sometimes called NT Services). When they are installed with something like a –Service command-line argument to a run of the Service program itself, install and uninstall are dependent on the Service being functional. However, Windows Installer has support for installing Services directly from the installation package with no requirement to run the Service executable to install it. Consequently, installation and removal of the Service are controlled more safely.
Repair
It's not unusual for files that belong to a product to get accidentally deleted. Windows Installer has repair features that restore an application that is broken because of missing files or Registry entries. If the installation marks a file or a Registry entry as "key," Windows Installer has the capability to restore the file or entry automatically if it's missing. When you go to Add/Remove Programs, a Repair choice is offered, along with other choices to uninstall or modify the installed features.
Repair is probably the feature that most often surprises developers. They are generally familiar with the idea that a product can be installed and then manipulated afterwards by adding new files or removing unwanted ones, only to find that the repair mechanism restores the files or Registry keys to the initial installation state. Users too are sometimes surprised when they remove a shortcut and move it to some other location, only to find that Windows Installer restores it through a repair.
64-bit
There is support in Windows Installer for installing applications onto 64-bit Windows operating systems. This doesn't just mean that you can install 32-bit applications onto 64-bit systems, it means that Windows Installer is likely to be the only way to install 64-bit applications onto a 64-bit system.
Sharing Files
Sharing has always been an important aspect of installations. The sharing issues are largely responsible for the situation popularly (or unpopularly) known as "DLL Hell." You need to work out which Microsoft DLLs need installing to support your product, and consequently run the risk of creating an incompatible set of system DLLs. Or you might have shared components in your company's products that all need to be installed and managed correctly on client systems. This is becoming less of an issue since Windows 2000 introduced Windows Protected Files, a feature that prevents installations from replacing critical system files. Windows Installer does not even attempt to replace those protected files that are considered to be part of the OS.
Sharing in Windows Installer uses reference counts for each unique component. You still need to follow rules, as you'll see later, but the Windows Installer component sharing mechanism is much more robust than previous schemes.
System Integration
Products installed with Windows Installer are integrated into Windows. APIs and COM objects can report information about installed products to a detailed level. In addition, a Windows Management Instrumentation (WMI) provider reports the content and configuration of installed products. If you ever wondered whether there is a way to discover accurately what products are installed on a system, the fact that there are standard API calls is a vast improvement compared to prowling the Registry looking for products. These APIs not only return detail about potentially every file installed by a product, they also allow the application code itself to integrate with the installation and modify installed components on the fly. The APIs also allow access to installation packages (MSI files). For example, it's relatively easy to query the contents of an installation package and compare the contents with a version of that package that is installed on the system.
.NET
Windows Installer has built-in support for installing .NET assemblies into the Global Assembly Cache (GAC). This is likely to be the only way you should install assemblies into the GAC. Yes, Microsoft supplies the Gacutil.exe utility in the development environment, but this program knows nothing about the Windows Installer reference-counting scheme, so shared assemblies installed into the GAC require Windows Installer to maintain correct shared-installer reference counts.
For the System or for Current User
When you start installing a product you are often asked if it's being installed for you (private to your account on the system), or whether it's being installed for everyone. These generally affect whether, for example, certain Registry entries are written to the HKEY_CURRENT_USER (HKCU area) or to HKEY_LOCAL_MACHINE (HKLM). If you assume that the target user is in fact the current user of the system, this means that the application should not be visible to other users. But think about the mechanics of COM registration, where code in the DllRegisterServer entry point creates COM registration entries on the system. You'll realize that there is no way that the code in DllRegisterServer knows whether the installation is per-user or per-machine, so the registration code cannot know which Registry location is the correct one, HKLM or HKCU. The code in DllRegisterServer registers to the local machine Registry keys, so in effect an install for the current user leaves COM servers accessible to everyone on the system. It therefore makes a lot of sense to get COM servers out of the business of self-registration and have Windows Installer create the registration entries in the appropriate Registry location.
Security of Installation vs. Security of Product
When trying to install a product for a user who might not have the security privileges to install the product, there needs to be a way for this user to install the product without requiring those elevated privileges on a permanent basis. Windows Installer provides some ways to deal with these issues. One reason it helps with these issues is because it runs as a Windows Service and doesn't need to be constrained by the privileges of the current user. Another reason is because policies can be configured so you can perform an installation with elevated privileges on behalf of a user who is not privileged.
Updating and Deploying New Versions
Before Windows Installer, when you wanted to ship corrections to a product, perhaps you simply rebuilt the entire installation setup and sent it to your clients. However, you can't just ask your client to install the product, because you'd end up with two copies of the product on the system. However, if you're supplying a fix or an update you need to replace the existing installed product. Generally speaking, the incoming new installation would detect the existing one and uninstall it, or perhaps even arrange to completely install itself on top of the existing product. Another choice would be to produce a service pack to update the product, often requiring use of a separate tool to install the updates to the client system. To summarize, there have been a number of ways to deal with these maintenance issues. Windows Installer has some formal mechanisms for installing product updates and fixes.
Advertisement
You can think of advertisement as installation-on-demand. It can be particularly useful in corporate environments—you can have practically everything installed (shortcuts, Registry entries, and so on) except for the files. When you reference the advertised product, the installation starts installing the files from a network location onto the client system. Even after a product has been installed, perhaps some of its features will be advertised, so that when the advertised feature is first used this feature is installed.
The idea of advertised features is that you install a hook of some kind, typically a shortcut. Using this shortcut causes the feature to be installed. If the advertised feature consists of one or more COM components, there is a similar advertisement installation step that causes the component to be installed.
Running Your Own Code
Many of the observations made might give the impression that you can't add your own code to the installation process. In fact you can—when you do this it's called a custom action. Many types of custom actions allow you to run VBScript, executables, and call into a DLL, to quote a few examples. So that changes to the system can be provided with transactional behavior in mind, you can associate these custom actions with the install, the uninstall, and also the rollback process that occurs when an installation fails and everything done to the system is being undone to restore the system to its original state.
Source of Information : Apress The Definitive Guide to Windows Installer
|
|
0 comments
Post a Comment