locked
Assembly backward compatibility RRS feed

  • Question

  • Hi,

     

    I was wondering if someone could explain to me how backward compatibility works between two assemblies.

     

    I have a client that is currently using an Sdk component that I have developed. Eventually, I'll have to deploy another version of this Sdk. With this newer version, I'll also deploy a publisher policy to ensure that the framework redirects all client requests to the newer sdk component. SDK v2.0 must be backward compatible with SDK v1.0.

     

    What are the criteria that make 2 assemblies backward compatible?

    • Keep public types
    • Keep public and protected methods (name and signature)
    • Etc.

    I know that in "legacy" COM, the order in which methods were declared in an interface was important. This does not seem to be the case for .NET objects that are not ComVisible.

     

    Is there a document out there that lists what is required of an assembly to qualify as backward compatible?

     

    Thanks,

    Tuesday, July 3, 2007 10:17 PM

Answers

  • You are going about this the wrong way.  If you, right now, are already convinced that you can create a next version of the assembly that is completely compatible with the previous version, simply give it the same version number and sign it with the same key.  No need for a policy.  That takes crystal balls, pun intended.  If the client works well with the old version of your assembly, don't rub the ball.  If you're not sure and think it might work, use the policy.
    Tuesday, July 3, 2007 11:02 PM
  • Ah, misunderstood.  Well, the JIT compiler ultimately binds method invocations.  It uses the metadata to look up the referenced method, similar to Reflection.  The IL in A.exe will have a "token", an index into B.dll's method table for the type.  It will work when the new version of B.dll has that token refer to the same method.  I don't know the exact mechanics of this, I doubt it is just a simple table index.  If it were, publisher policies wouldn't work very often.
    Wednesday, July 4, 2007 7:21 AM
  • I did manage to find out how member references were resolved by the CLR. The info can be found in ECMA 335 document (Partition II - Section 22.25).

     

    Au revoir!

     

     

    Sunday, July 8, 2007 9:54 PM

All replies

  • You are going about this the wrong way.  If you, right now, are already convinced that you can create a next version of the assembly that is completely compatible with the previous version, simply give it the same version number and sign it with the same key.  No need for a policy.  That takes crystal balls, pun intended.  If the client works well with the old version of your assembly, don't rub the ball.  If you're not sure and think it might work, use the policy.
    Tuesday, July 3, 2007 11:02 PM
  • nobugz,

     

    Even if you were right, the question is not about whether I should use the publisher policy or not.

    The question is what makes two assemblies backward compatible.

     

    Does the order in which fields of a structure are declared have an impact?

    Does the order in which methods of an interface are declared have an impact?

    Etc.

     

    What I really need to know in fact is what goes on in the CLR when an assembly links with another assembly.

     

    Let's say I have assembly A.exe calling method MyClass.MyMethod of assembly B.dll. So, at compile time, A has a reference on B. Now, suppose I replace B.dll with NewB.dll after deployment. A is still calling MyClass.MyMethod, even if both methods are not defined at the same address in their respective assembly. This looks as if reflection was used to locate method MyClass.MyMethod.

     

    So I guess it boils down to this: When A calls B, does it use reflection to locate what it is looking for, or does it jump to an address in assembly B known at compile time? If it uses reflection, then signatures and type visibility are important. If it uses an address, the order in which methods are declared also plays a role in backward compatibility. From what I saw so far, reflection is used.

     

     

     

    Wednesday, July 4, 2007 5:57 AM
  • Ah, misunderstood.  Well, the JIT compiler ultimately binds method invocations.  It uses the metadata to look up the referenced method, similar to Reflection.  The IL in A.exe will have a "token", an index into B.dll's method table for the type.  It will work when the new version of B.dll has that token refer to the same method.  I don't know the exact mechanics of this, I doubt it is just a simple table index.  If it were, publisher policies wouldn't work very often.
    Wednesday, July 4, 2007 7:21 AM
  • I did manage to find out how member references were resolved by the CLR. The info can be found in ECMA 335 document (Partition II - Section 22.25).

     

    Au revoir!

     

     

    Sunday, July 8, 2007 9:54 PM