Assemblies — Referencing and servicing

Every assembly has two life forms.


At development time, it is referenced by other assemblies. Its assembly version number is burned into assemblies that reference it.


At runtime, it is loaded by the assemblies that reference it. The exactly version of the assembly loaded is determined by the reference version and the servicing policy.


Normally, the form used at development time (SDK version) is shipped once, and rarely (if ever) updated. While the form used at runtime is serviced numerous time.


This suggests that the SDK version and the released version don’t need to have the same assembly version number. This leaves so much freedom for you to decide how to version the SDK version and released version.


You can say SDK version = released version. (This is .Net framework’s model. Applications directly reference assemblies in %windir%\Microsoft.Net\Framework\<framework version>, where the released version of .Net framework reside.)


Or you can say, SDK version = 0.0, and released version = real number. And publisher policy floats 0.0 to the released version. (This is Windows’ model. For example, the referenced version for common control is For every released version of common control (QFE/SP), the version number is increased, and publisher policy is shipped to redirect version to the real number.)


Or you can say, SDK version = LKG (Last Know Good) version, and release version = real number. And publisher policy redirects LKG version to released version. (This is VC8’s model. Every VC8 binary references Microsoft.VC80.CRT LKG version 8.0.50608.0. The RTM version of Microsoft.VC80.CRT is 8.0.50727.42. Publisher policy redirects 8.0.50608.0 to 8.0.50727.42.)


So what is your model?

Comments (4)

  1. derekgreer says:

    Hey Junfeng. Sorry for posting my question here, but your contact site at seems to be out of commission and the "Questions and Topics suggestions" blog you set up doesn’t seem to be enabled to add new questions.

    Referencing your blog concerning "Assembly Identity — ReferenceIdentity and DefinitionIdentity, Comparison and Transformation", I have run into very confusing behavior of the AssemblyName.ReferenceMatchesDefinition() method. I have two AssemblyName objects specifying different version numbers and different public key tokens and the method is returning "true". Can you please explain this behavior? Here is the test code I am running:


    public void WeirdTest()


    string assemblyName1 = "Microsoft.ApplicationBlocks.UIProcess, Version=, Culture=neutral, PublicKeyToken=017b55c343bf0690";

    string assemblyName2 = "Microsoft.ApplicationBlocks.UIProcess, Version=, Culture=neutral, PublicKeyToken=d950bf28eab55805";

    AssemblyName an1 = new AssemblyName(assemblyName1);

    AssemblyName an2 = new AssemblyName(assemblyName2);

    bool matches = System.Reflection.AssemblyName.ReferenceMatchesDefinition(an1, an2);

    if (matches)


    System.Diagnostics.Debug.WriteLine(String.Format("matches: {0} = {1}", assemblyName1, assemblyName2));



  2. Sorry about the contact page. The question blog comment days are expired. I’ll open a new one.

    We find a bug in ReferenceMatchesDefinition late in RTM milestone. It was determined that the bug does not meet RTM bar. It will be fixed in SP1.

    I am not happy but I believe it is the best option for RTM.

  3. derekgreer says:

    Thanks for the information Junfeng. For future reference, is there a publicly accessible site people can refer to to check whether a given behavior is a bug or not?

    Derek Greer

  4. I don’t think there was a site for that before.

    Now you can open a bug in MSDN feedback and track it. Someone from CLR will triage it.

Skip to main content