Sxs’ runtime behavior is built on top of the concept of Activation Context. (For more details on Activation Context, please visit MSDN. I have published an article on it early.)


You can use API CreateActCtx to create an activation context. CreateActCtx requires a source manifest. Optionally, you can also specify an assembly directory (which is commonly referred as application base.), language, processorArchitecture, and resource name if the source is a PE image. For the optional parameters, if they are not specified, they are automatically resolved from the source manifest and the OS environment.


The source manifest can include dependencies on other Sxs assemblies. For example, most people use a Sxs manifest that depends on comctl32 v6 to enable Windows XP Look & Feel.

c:\more fuslogvw.exe.manifest

<assemblyIdentity version="" name="Microsoft.FUSLOGVW" type="win32" />
<description>Microsoft .Net Framework Assembly Binding Log Viewer</description>

When the source manifest includes dependencies, Sxs needs to resolve the dependencies. The process of mapping the dependencies to a physical Sxs manifest file is called binding.


Binding can be divided into two phases: Policy and Probing.




There are two kinds of binding policies in Sxs: Application Policy and Publisher Policy.  Just like CLR, application policy is applied to the whole application, while publisher policy is applied to a single assembly for all the applications.


The behaviors have some subtle differences in different OSes:


  1. In Windows XP, if the application policy is applied, the publisher policy is ignored. Otherwise, the publisher policy will be applied.
  2. In Windows Server 2003 and later, the publisher policy will be applied, even after the application policy is applied.  

The Windows Server 2003 behavior is the same as CLR.


Windows ships a publisher policy for every QFE to windows Sxs assemblies. I haven’t yet seen anyone use application policy inside Microsoft.




After binding policies are applied, Sxs will start probing for the manifest file.


The probing sequence is documented in MSDN Assembly Searching Sequence. There are also some subtle behavior differences in different OSes:


  1. In Windows XP, if Sxs finds a dll with the same name, but the dll does not have a Sxs manifest in its resource, Sxs will fail the probing.
  2. In Windows Server 2003 and later, when the same thing happens, Sxs will ignore the dll, and keep looking for the manifest file.  

For portability you should always embed the manifest into the dll if possible.




You are allowed to wildcarding certain attributes in dependencies. In our example above, processorArchitecture and language are wildcarded.


When the attribute is wildcarded, Sxs will use some heuristics to figure out which value to use for probing.


For processorArchitecture, the heuristics is following:


1.      If processorArchitecture is explicitly specified and the processorArchitecture is Wow64, the fallback is x86. Otherwise, nofallback.
2.      If the processorArchitecture is wildcarded, the fallback list is of the following sequence:
a.      32 bit OS: 

In Windows XP and Server 2003: x86->None

In Windows Vista: x86->MSIL->None
b.      64 bit OS: 

In Windows XP and Server 2003: IA64/AMD64->None

In Windows Vista: IA64/AMD64->MSIL->None


For language, Sxs queries the system language settings, and probe the manifest from more specific culture to no culture. For example: en-us -> en -> None.


Only processorArchitecture and language are allowed to be wildcarded.


Case Sensitivity


Sxs is case sensitive when comparing attributes. Be sure that the casing of the attribute is the same in the dependencies and in the manifest file.