I'm working on a C# 3.5 assembly that is consumed by many different applications in an enterprise server environment. I would like to add some properties to an existing C# class (not abstract) and maintain backwards compatibility with current clients without recompiling. It’s a strongly named 3.5 assembly. Existing client applications will not be recompiled. Instead we use publisher policy assemblies to re-direct existing clients to the updated version.
What are the rules for maintaining this type of class backward compatibility?
I'm looking for some set of rules I can validate my code changes against.
After my current attempts at updating the class clients are throwing a "The located assembly's manifest definition does not match the assembly reference" exception.
The best reference is Justin's answer: A definite guide to API-breaking changes in .NET
@Justin - if you ever post this as an answer, I'll give you the check.
You have to maintain the same assembly version (i.e. don't increment it across builds) — see the AssemblyVersionAttribute in MSDN.
Also, you could leverage assembly binding redirects, but that involves config file changes which I don't expect to be desirable in your case.
At his point error that you are getting is not related to compatibility between classes, but rather problem loading assembly - see The located assembly's manifest definition does not match the assembly reference if it helps.
Adding properties/methods to exisitng class should be ok for backward compatibility. Removing fields/methods/properties, changing class to struct, changing base class is definitely not. Modifying constants, enum values is dangerous.
来源：https://stackoverflow.com/questions/5084921/rules-for-c-sharp-class-backward-compatibility-avoiding-breaking-changes