Frequently asked Questions about COM and Windows installer (MSI) / Application Packaging

What does the common language runtime do?
The common language runtime manages the execution of code and provides services such as cross-language integration, code access security, object lifetime management, and debugging and profiling support. Search for "Common Language Runtime" in the MSDN Library (msdn.microsoft.com/library/).


What's the difference between managed and unmanaged code?
Code developed with a language compiler that targets the common language runtime is called managed code. All code based on Microsoft intermediate language (MSIL) executes as managed code. Managed code is self-describing; it contains metadata that describes every element managed by the common language runtime. The runtime uses the metadata to provide services.
Code that runs outside the runtime and does not contain metadata is called unmanaged code. Examples of unmanaged code are COM components, ActiveX interfaces, and Win32 API functions. Unmanaged code executes in the common language runtime environment with minimal services.


Can I add managed code to an existing application?
Few developers are able to rewrite existing applications completely as managed (.NET) code. Instead, you can combine managed and unmanaged components in one installation. Code that contains a mix of managed and unmanaged elements is called interoperable code.
The common language runtime supports COM interoperability (interop). For backward compatibility, COM interop provides access to existing COM components without requiring you to modify the original components. COM interop also enables your COM clients to access managed code as easily as they access other COM objects. This is accomplished by adding information to the system registry so .NET components are called as though they were COM components. At runtime, the common language runtime marshals data between COM objects and managed objects as needed.
Search for "Interoperating with Unmanaged Code" in the MSDN Library (msdn.microsoft.com/library/).


What is an assembly?
An assembly is the primary building block of a .NET application. An assembly contains its own naming, binding, versioning, deployment, and configuration information. It consists of 2 elements: a manifest, which is the meta data that describes information about the assembly and any resources it depends on; and a set of instructions in the form of Microsoft Intermediate Language (MSIL) code that is executed when the assembly is referenced.
You can group assembly elements into a single file assembly, which incorporates the manifest into a portable executable (PE) file, which can be an .EXE or .DLL, with the source code. You also can create a multifile assembly consisting of modules of compiled code, resources, or other files required by the application. In a multifile assembly, the manifest can be a standalone file or it can be incorporated into one of the PE files in the assembly.

When you add a .NET assembly to an installation, Windows Installer Editor creates entries in the MsiAssembly and MsiAssemblyName tables.
See Assemblies in the Windows Installer SDK Help.


How does .NET reduce file sharing conflicts?
An important benefit of .NET installations is the reduction of file sharing conflicts. With the common language runtime, the assembly is described by a manifest; the registry is no longer relied upon for storing and accessing the COM activation data. This allows components to be fully isolated from each other.
Assembly sharing is accomplished in several ways:
a) Global Assembly Cache
To install .NET assemblies that are intended to be shared by many applications on the computer, make sure they are strongly named and install them into the Global Assembly Cache, which is a machine-wide code cache. Do not install assemblies into the Global Assembly Cache unless they specifically need to be shared. The Global Assembly Cache is available only if the .NET Framework is installed on the destination computer.
b) Side-by-side
To safely share COM or Win32 assemblies among multiple applications and to minimize .DLL conflicts, use side-by-side assembly sharing. Instead of having a single version of an assembly that assumes backward compatibility with all applications, side-by-side assembly sharing enables multiple versions of a COM or Win32 assembly to run simultaneously on the destination computer. Side-by-side assembly sharing is available only on Windows XP or later. See Side-by-Side Assemblies in the Windows Installer SDK Help.
c) Private assembly
To reserve a Win32 assembly for the exclusive use of one application, install it in a directory that is private to the application, typically the application directory. This is called a private assembly. The dependency of the application on the private assembly is specified in an application manifest file. On operating systems earlier than Windows XP, a copy of the private assembly and a .local file is installed into a private directory for the exclusive use of the application. A version of the assembly is also globally registered on the system and made available for any application that binds to it. The global version of the assembly can be the version installed with the application or an earlier version.


I thought .NET meant I could use XCOPY to install applications without registration. Why do I need to build a Windows Installer installation?
For a .NET application that uses only managed code and private assemblies, the installation process can be as simple as copying files to the destination computer. Most developers, however, still need to create a compressed, single-file installation that is easy to deploy and that provides a friendly interface to the end user.
.NET applications that use shared assemblies, or that have a mix of managed and unmanaged code, cannot be installed via XCOPY. You should use the Windows Installer service for installations that do any of the following:
a)Install COM files
b)Install assemblies to the Global Assembly Cache
c)Require user information during the installation
d)Require security
e)Create a shortcut
f)Require elevated privileges to install on a locked-down computer

By creating a Windows Installer installation for your .NET applications, you can take advantage of the services Windows Installer provides: installation, repair, and removal of assemblies; roll back; install-on-demand; patching; and advertisement.


How does Windows Installer Editor support .NET installations?
Windows Installer Editor lets you install .NET assemblies into the Global Assembly Cache, or as side-by-side or private assemblies. It also lets you create mixed installations by registering .NET assemblies with COM.
If the .NET Framework is installed on your computer, Windows Installer Editor can automate the process as follows:
a) Find all files in multifile assemblies and add them to the installation.
b) Scan for assembly dependencies and add them to the installation.
c) Determine attributes for registering the assembly files and add them to the MsiAssemblyName table.
d) Add registry keys for COM interop.

Frequently Asked Questions about Windows Installer (MSI) Packaging.

These are the most Frequestly asked queries, which I have compiled from lots of places and have put together.

I have added more questions in other post which can be accessed by below link.

http://msiworld.blogspot.com/2011/11/frequently-asked-questions-about-com.html

Q. What is Windows Installer?

A. Windows Installer is a system service for installing and managing applications. It provides a standard method for developing, customizing, installing, and updating applications.

Q. What basic functionality is provided by Windows Installer?

A. Windows Installer provides the following basic functions:

• Transactional operations. All installation operations are transactional. For each operation that Windows Installer performs, it generates an equivalent undo operation that would undo the change made to the system. If a failure occurs during the middle of an installation, Windows Installer can roll back the machine to its original state.
• Self-healing. Windows Installer supports "self-healing" abilities for applications. Applications can detect common installation problems at launch, like missing files or registry keys, and automatically repair themselves.
• Installation on demand. Windows Installer supports on-demand installations of application features. For example, the spelling checker in Microsoft Office Word may not be installed by default, but a user can trigger an on-demand installation of this feature.
• Installation in locked-down environments. In fully locked-down environments, users don't generally have permission or the ability to install applications. In most cases, they don't have write-access to the Program Files folder of their computers or to the HKEY_LOCAL_MACHINE registry location. If an administrator approves an installation package by means of Group Policy, for instance, Windows Installer can perform an installation on the user's behalf.
• State management. Windows Installer provides a set of standard Win32® application programming interfaces (APIs) and automation interfaces for applications and administrators to use for querying the installation state on the machine. The APIs allow querying of the current state, verification of the existing state, repair of a corrupted state, and transition from one state to another.

Q. What versions of Windows include Windows Installer?

A. Microsoft Windows 2000, Windows Millennium Edition (Windows Me), and Windows XP include Windows Installer. Windows 2000 includes version 1.1 of Windows Installer, Windows Me includes version 1.2, and Windows XP includes version 2.0. Windows 2000 SP3 also contains version 2.0 of Windows Installer.

Q. Why are multiple MSIExec.exe processes running on my machine during an installation?

A. A number of MSIExec processes can be running during an installation. The reason for this is that Windows Installer uses a client-server model for performing installations. Additionally for security reasons, Windows Installer hosts DLL and script custom actions in a "sandbox" process. Depending on how the install was initiated, one of the MSIExec processes can be the client process. Another MSIExec process is Windows Installer service. Any remaining MSIExec processes are usually sandbox processes for hosting custom actions. The determination as to which MSIExec process will serve as the sandbox process for a script or DLL custom action depends in part on whether the custom action will run elevated or impersonated and whether the custom action is 32-bit or 64-bit.

Q. What is an MST, and why it is used?

A. Whenever there is a vendor supplied MSI, then it is not recommended to do capture the MSI, hence all the changes need to be done in the MSI are done is a Microsoft Transform. Then this MST file is applied on the MSI with the following command line.

MSIEXEC /I {path}\file.msi TRANSFORMS={path}\file.mst /q

Where {path} is the location of the folder where MSI and MST are kept.

Q. What are the differences between small, minor, and major updates?

A. A small update is a product update that changes a few files or possibly adds some new content. A minor update is a product update that makes enough changes to warrant changing the product version for the product, whereas a major update is a product update with a large number of changes that warrants a change in the product code.

It's sometimes easier to think of a small update as a "hotfix" or Quick Fix Engineering (QFE) update, a minor update as a service pack, and a major update as a product upgrade.

Small and minor updates can be considered almost equal in that the only real difference is that a minor update has a change to the ProductVersion whereas a small update does not. The rules that they follow and application of the patch are the same. Application of small and minor update patches requires explicit reinstallations. Major updates are not subject to that limitation and a reinstallation is not required for patch application. Additionally small and minor update patches are limited in the changes that can be made to the feature-component structure for the package. Significant changes can be made to the feature-component structure in the scope of a major update.

Q. What is the Logical structure of package?

A. A package describes the installation of a full product (Windows Installer does not handle dependencies between products) and is universally identified by a GUID. A product is made up of components, grouped into features.

Components

A component is the minimal part of a product—each component is treated by Windows Installer as a unit: the install developer cannot, for example, use a condition to specify to install just part of a component. Components can contain files, groups of files, directories, COM components, registry keys, shortcuts, and other data. The end user does not directly interact with components.

Components are identified globally by GUIDs, thus the same component can be shared among several features of the same package or multiple packages, ideally through the use of merge modules (although, for this to work correctly, different components should not share any sub-components).

Key paths

A key path is a specific file, registry key, or ODBC data source that the package author specifies as critical for a given component. Because a file is the most common type of key path, the term key file is commonly used. A component can contain at most one key path; if a component has no explicit key path, the component's destination directory is taken to be the key path. When an MSI-based application is launched, Windows Installer checks the existence of these critical files or registry keys (that is, the key paths). If there is a mismatch between the current system state and the value specified in the MSI package (e.g., a key file is missing), then the related feature is re-installed. This process is also known as self-healing or self-repair. No two components should use the same key path.

Features

A feature is a hierarchical group of components—a feature can contain any number of components and other features (a feature contained in another feature is called a "subfeature"). Most installation programs display a "custom setup" dialog box at run time, from which the end user can select which features to install or remove.

The package author defines the product features. A word-processing program, for example, might provide features for the main program executable, the program's help files, and optional spelling checker and stationery modules.

Q. What is Advertisement?

A. Windows Installer can advertise a product rather than actually installing it. The product will appear installed to the user, but it will not actually be installed until it is run for the first time (by means of a Start menu shortcut, by opening a document that the product is configured to handle, or by invoking an advertised COM class).

Q. What is Installation on demand?

A. Similar to advertisement, it consists in the installation of features as soon as the user tries to use them.

Q. How to do Diagnostic Logging?

A. Windows Installer supports detailed logging as a powerful diagnostic tool. Logging can be enabled in the following four ways:

Command-line: If installing an MSI package from the command-line, the /L switch can be used to enable logging. For example, the following command installs Package.msi and outputs verbose logging to c:\Package.log:

msiexec /i Package.msi /l*v c:\package.log

Windows Registry: The following registry value can be used to enable verbose logging:

Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

Value Name: Logging

Type: REG_SZ

Data: voicewarmup

The resulting log is named MSI###.log (where "###" is a unique random identifier) and is placed in the system's Temp directory.

Group Policy: The following Group Policy setting can be used to manage logging on multiple systems:

Computer Configuration -> Administrative Templates -> Windows Components -> Windows Installer -> Logging.

Windows Installer API: If installing an MSI package programmatically, the MsiEnableLog function call can be used to create a log file and determine the logging level for the life of the calling process.

Although verbose logs are very useful for diagnosing Windows Installer problems, they can be very long and difficult to read without practice. A quick way to find the location of a problem in the log is to open it in a text editor (such as Notepad) and search for the phrase "Return Value 3". This entry commonly appears in logs close to the point where a critical error has occurred. The Windows Installer SDK provides a tool called WiLogUtl, which parses and annotates Windows Installer log files.

Q. Why does the package go for Self Healing first time the user launches the Application?

A. If the package is containing some HKCU entries then the package will always go for self healing for the first time. This happens because the HKCU keys are only installed for the current user present while installing the package and not all the users as it is the property of the HKCU. So, if other user logs in then there is a mismatch between the current system state and the value specified in the MSI package (e.g., a key file is missing), then the related feature is re-installed. This is called the Self Healing.

Q. How do detect the MSI version on the computer?

A. If you want to check the version of the Windows Installer on your system, check the version of MSI.DLL in the Windows\System 32 folder.