This project is read-only.

Design Meeting Notes - June 28, 2012

Code contracts


Currently we are using code contracts just for runtime verification of preconditions and don’t build the reference assemblies.

Any users that derive their types from the types defined in EF that want to use code contracts won’t be able to access the contracts that we defined.

Options considered

  1. Ship the reference assembly in the same NuGet package as the main assembly
    • This would unnecessary bloat the package for the users that don’t use code contracts. The reference assembly is about half the size of the main one.
    • It is possible to use explicit assembly references in the package so the reference assembly wouldn’t be added as a project reference as it’s not used during runtime.
    • Currently we don’t specify postconditions, so the reference assembly would be of limited value even to code contracts users.
  2. Ship the reference assembly in a separate NuGet package
    • This wouldn’t bloat the main package, but would be less discoverable and still have all the other cons listed above
  3. Don’t ship the reference assembly, but build it
    • Users with access to the source code will be able to build it when needed.


We won’t ship the reference assembly unless we get some requests to do otherwise. However we need to improve the contracts at least on the public surface and consider enabling static verification.

Last edited Dec 14, 2012 at 6:25 PM by ajcvickers, version 2