title: Rules for C# class backward compatibility/avoiding breaking changes
body: <p>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.</p>
  
  <p>What are the rules for maintaining this type of class backward compatibility?</p>
  
  <p>I'm looking for some set of rules I can validate my code changes against. </p>
  
  <p>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.</p>