| Microsoft XML Core Services (MSXML) 5.0 for Microsoft Office |  |
| Microsoft XML Core Services (MSXML) 5.0 for Microsoft Office | |
Creating an application manifest will work when you first deploy your application with MSXML 5.0. But what happens if you want to control which version of MSXML your application uses as new versions of it are released?
For example, you might want to:
Windows XP enables assembly publishers, application publishers, and administrators to change side-by-side assembly dependencies after deployment with publisher configuration and per-application configuration.
Publisher configuration redirects applications and assemblies that have a default dependence on one version of a side-by-side assembly, so that they use another specified version instead. 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 when you install a service pack that contains 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.
Per-application configuration overrides the default configuration and publisher configuration on a per-application basis. This redirects the dependence of a specific application from one version of a side-by-side assembly to another specified version of the assembly.
A per-application configuration might be necessary if a particular application requires an assembly version that is different from the version that is normally specified as a default or publisher configuration.
The following table shows an example of a hypothetical configuration in chronological order. Consider two applications, A and B, which both use component (assembly) X.
| Action | Application A uses component X version | Application B uses component X version |
|---|---|---|
| Initial state. Component X 1.0 is installed. The application manifest of Application A (Manifest A) points to it. Application B does not have a manifest. | 1.0 | None. Cannot use X. |
| Install X version 1.1. | 1.0 | Cannot use X. |
| Change Manifest A to point to X 1.1. | 1.1 | Cannot use X. |
| Create an application manifest for Application B (Manifest B) to point to X 1.1. | 1.1 | 1.1 |
| Install X 1.2. | 1.1 | 1.1 |
| Publisher configuration file installed, redirecting everything from X 1.0 to 1.1. | 1.1 | 1.1 |
| Publisher configuration file installed, redirecting everything from X 1.1 to 1.2. | 1.2
(Manifest A still points to 1.1.) |
1.2
(Manifest B still points to 1.1.) |
| Manifest A is updated to point to 1.2. | 1.2 | 1.2
(Manifest B still points to 1.1.) |
| X 1.3 installed. | 1.2 | 1.2 (Manifest B still points out to 1.1) |
| Publisher configuration installed, redirecting everything from X 1.1 to 1.3. | 1.2 | 1.3
(Manifest B still points to 1.1.) |
| Manifest B is updated to point to 1.3. | 1.2 | 1.3 |
| X 1.4 installed. | 1.2 | 1.3 |
| Publisher configuration installed, redirecting everything from 1.2 to 1.4. | 1.4
(Manifest A still points to 1.2.) |
1.3 |
This example demonstrates some of the possible situations you should pay attention to when using publisher and application configuration.
For more information about publisher and application configuration, see the Windows Platform SDK.