St. Louis Day of .NET – Code Contracts

This is part of a series of posts containing my notes from the sessions I attended at the 2011 St. Louis Day of .NET conference.

This series does not attempt to give complete accounts of the information presented in each session; it is just a way to capture the bullet points, notes, and opinions that I recorded while attending the conference. I have previously posted a list of all of the session materials and sample code that I have been able to find online, so if you are looking for a more precise account of a session, try looking there.

Jeff Ayers presented a session on a very new add-on to Visual Studio, Code Contracts.  I have been reading Dino Esposito’s ongoing series of articles about Code Contracts in MSDN Magazine, and was interested in hearing another perspective on the technology.  The verdict seems to be that the technology is not quite ready for prime-time.  Here are my notes from the session..

  • Code Contracts Standard/Premium from Microsoft DevLabs is the Visual Studio plug-in that is needed to enable the technology.  Available from
  • Description from the download site: "Code Contracts provide a language-agnostic way to express coding assumptions in .NET programs. The contracts take the form of pre-conditions, post-conditions, and object invariants. Contracts act as checked documentation of your external and internal APIs. The contracts are used to improve testing via runtime checking, enable static contract verification, and documentation generation. Code Contracts bring the advantages of design-by-contract programming to all .NET programming languages."
  • An example of a code contract in C# is data validation that that be defined simply by adding attributes to a method or class.
  • Looking at the above description of code contracts, an example  "coding assumption" is that an input value to a method will be between 1 and 10.  This would be a "pre-condition" for the execution of the method.  The method is decorated with an attribute that specifies the contract conditions.  The contract conditions are verified via "runtime checking".  The attributes also enable "static verfication" and "documentation generation".
  • Contracts are checked at run-time.
  • After working with Code Contracts for three weeks, the presenter believes that the tool, while useful, is not completely mature.  The session demonstrations illustrated the difficultly in working with the toolset at the present time.
  • System.Diagnostics.Contracts is the namespace to include to gain access to the code contract functionality
  • Exceptions of type "ContractException" cannot be caught.  (Perhaps something that will change in the future?)  Instead, you can specify the type of exception to be thrown when a contract is violated.  For example, you can choose to throw an ArgumentException.  Those exception types can be caught as usual.
  • Examination of the IL revealed that a lot of additional code is generated by the compiler to handle contracts.  The presenter stated that while good for producing developer feedback, contracts should not yet be included in production builds, at least for object invariant contracts.  It adds too much overhead to a running application, affecting performance.
  • The tool does not work for WCF, because the WSDL doesn’t reflect the contract feedback that is so useful to users of the service (developers).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: