.NET 4.0’s game-changing feature? Maybe contracts…

Update: As Chris Nahr pointed out, there’s a blog post by Melitta Andersen of the BCL team explaining this in more detail.


Obviously I’ve been looking at the proposed C# 4.0 features pretty carefully, and I promise I’ll blog more about them at some later date – but yesterday I watched a PDC video which blew me away.


As ever, a new version of .NET means more than just language changes – Justin van Patten has written an excellent blog post about what to expect in the core of thee framework. There are nice things in there – tuples and BigInteger, for example – but it was code contracts that really caught my eye.


Remember Spec#? Well, as far as I can tell the team behind it realised that people don’t really want to have to learn a new language – but if the goodness of Design By Contract can be put into a library, then everyone can use it. Enter CodeContracts


Actual examples are relatively few and far between at the moment, but the basic idea is that you write your contracts at the start of methods – not in attributes, presumably because that’s too limiting in terms of what you can express – and then a post-build tool will “understand” those contracts, find potential issues, and do a bit of code-rewriting where appropriate (e.g. to move the post-condition testing to the end points of the method). Object invariants can also be expressed as separate methods.


Rather than guess at the syntax in this blog post I highly recommend you watch the PDC 2008 video on both this and Pex (an intelligent code explorer and test generator). The teams have clearly thought through a lot of significant issues:


  • Contracts can be enforced at runtime, or stripped out for release builds. (I’ll be interested to see whether I can keep the pre-condition checks in the release build, just removing invariants and post-conditions etc.)
  • If you’re stripping out the contracts, you can still have them in a separate assembly – so if you supply a library to someone, they can still have all the Design by Contract goodness available, and see where they’re potentially violating your preconditions
  • Contracts will be automatically documented in the generated XML documentation file (although this has yet to be implemented, I believe)
  • Interfaces can be associated with contract classes where the contracts are expressed. (They couldn’t be in the interface, as they require method bodies.)
  • Pex will be able to generate tests in MS Test, NUnit and MbUnit. (Hooray! This got a massive cheer at PDC.)

Now I should point out that I haven’t tried any of this – I’ve just watched a video which was very slick and obviously used a well-tested scenario. If this genuinely works, however, I think it could change the way mainstream developers approach coding just as LINQ is changing the way we see data. (Obviously there’s nothing fundamentally new about DbC – but there’s a difference between it existing and it being mainstream.)


I’m really, really excited about this :) Definitely time to boot up the VPC image when I get a moment…

9 thoughts on “.NET 4.0’s game-changing feature? Maybe contracts…”

  1. This will be great, I accomplish something similar using Umbrella’s ValidationExtensionPoint but something that can hint unit tests, documentation, as well as run time validation would be ideal.

  2. > I’ll be interested to see whether I can keep the pre-condition checks in the release build, just removing invariants and post-conditions etc.

    It seems that’s just what you’ll get if you enable the conditional symbol for CodeContract, but don’t run their assembly postprocessor.

  3. I haven’t watched this video yet but I’m also very excited about Code Contracts. I’ve wanted design by contract in C# ever since I wrote my first ArgumentNullException!

  4. Microsoft seems to be finally going for code quality with contracts, AKA beefed up asserts, and static analysis tools.

    The cost of your code is not the initial development cost but the full cost over the lifecycle of the product. Looking at only initial development costs will greatly shorten the application’s life-span and force you to spend much more money to rewrite/architect it in 2 years. We strive for at least a 5 year lifespan for our applications.

  5. …we can’t know whether the Nullable facet (i.e. a persistence constraint) applies in this context.

    This distinction makes me think of the contract feature which is coming in .NET 4.0. In that in both situations we are really looking for more validation.

    It also makes me wonder whether…

Comments are closed.