Microsoft XML Parser 4.0 B2 and Windows XP

Microsoft Corporation

July 2001

Summary: The following article discusses the relationship between Microsoft XML Parser (MSXML) 4.0 and Microsoft Windows XP, and how to create an application manifest in order to use MSXML 4.0. (5 printed pages)

Note   This document explains important features relevant only to Microsoft® Windows® XP. If you are using Windows 2000, Windows NT®, Windows Me, or Windows 98, you can disregard the following information.

Contents

Introduction
What Does This Mean to You?
What Happens When Another Version of MSXML is Released?

Introduction

Microsoft® Windows® XP enables applications to safely share assemblies. When MSXML 4.0 is installed on Microsoft Windows XP, it is installed as a shared side-by-side assembly. A shared side-by-side assembly is installed by Windows Installer into the managed assembly store of the system. Side-by-side assemblies are authored so that multiple versions can run at the same time without affecting each other. These assemblies are not registered globally on the system, but they are globally available to applications that specify a dependence on the assembly in application manifests.

Windows XP Side-by-Side installation should not be confused with the side-by-side installation provided in previous versions of MSXML. The previous side-by-side installation was based on changing GUIDs and ProgIDs. Windows XP, however, supports the side-by-side use of objects from different versions identified with the same ProgIDs and GUIDs. In this article, "side-by-side" will always refer to Windows XP Side-by-Side installation.

For Windows XP, you specify dependencies with manifests. There are two types of manifests:

An assembly manifest is an XML file that describes a side-by-side assembly. It describes the names and versions of side-by-side assemblies, files, and assembly resources. It also describes the dependence of the assembly on other side-by-side assemblies. An assembly manifest contains binding and activation information—such as information about COM classes, interface stubs, and type libraries—that traditionally has been stored in the registry. For side-by-side assemblies to be correctly installed, activated, and executed, the assembly manifest must always accompany an assembly on the system.

An application manifest describes the names and versions of shared side-by-side assemblies to which the application should bind at a run time. Application manifests are either copied into the same folder as the application's executable file or are installed as a resource in the application's executable file.

What Does This Mean to You?

To use MSXML 4.0, you will need to create an application manifest.

1. Copy and paste the following sample manifest into any text editor.
   Copy

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <assemblyIdentity
       version="1.0.0.0"
       processorArchitecture="X86"
       name="Microsoft.Windows.mysampleApp"
       type="win32"
   />
   <description>Your app description here</description>
   <dependency>
       <dependentAssembly>
           <assemblyIdentity
               type="win32"
               name="Microsoft.MSXML2"
               version="4.0.0.0"
               processorArchitecture="X86"
               publicKeyToken="4495b64144ccf1df"
               language="*"
           />
       </dependentAssembly>
   </dependency>
   </assembly>
   
   

2. Update the values for your application <assemblyIdentity> as appropriate for your application and the processorArchitecture. The application <assemblyIdentity> is the first <assemblyIdentity> listed in the manifest.
   • <assemblyIdentity> refers to the identity of your application. Update the values for version, processorArchitecture, and name to match your application.
   • <description> is optional. You should either include a brief description of your application or remove this tag.
3. Make sure that the values for version and publickKeyToken match the values in the assembly manifest installed with MSXML 4.0. You can find the assembly manifest in the special WinSxS/Manifest directory.
4. You can place a separate manifest file in the same directory as your application's executable file. Give it the same name as your application, adding the ".manifest" extension. For example, for a program named "test.exe", the manifest should be "test.exe.manifest".
5. As an alternative for new applications, you can include the application manifest in the application's binary executable header file. In this case, also add the following line to the application header file:
   Copy

   CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "YourApp.exe.manifest"
   
   

   The file system version takes precedence over the one in the resource section of the executable file.

You must use Windows Installer 2.0 package to deploy your applications.

What Happens When Another Version of MSXML Is Released?

Windows XP enables assembly publishers, application publishers, and administrators to change side-by-side assembly dependencies after deployment with publisher configuration files and application configuration files.

Publisher configuration redirects all applications and assemblies that have a default dependence on one version of a side-by-side assembly to use another specified version. Assembly publishers can implement a publisher configuration by authoring and installing publisher configuration files. Publisher configuration files override the default configuration specified by the application manifest. Note that a per-application configuration can override the publisher configuration with application configuration files.

Typically, a publisher configuration would be installed during a service pack installation that includes an assembly update. This enables the applications to use the updated assembly without having to rebuild all the affected applications. For example, an administrator might deploy an assembly update by redirecting all applications and assemblies on the system that use assembly version 1.0.0.0 by default to use version 1.1.0.0 instead. In this case, the new assembly version must be backward compatible.

The following example of a hypothetical configuration, in chronological order, will help explain this situation. Let's consider two applications, A and B, both of which use component (assembly) X.

This example shows potential advantages of this technology, as well as issues you should pay attention to. For more information about publisher and application configuration, see the Windows Platform SDK.