More on .NET 4.0 Code Contracts

  • 2 minutes to read
  • edit

Last month I talked about Code Contracts, which are one of the new features in .NET 4.0. Earlier today I was digging around in .NET Reflector looking for something totally unrelated when I came across the Microsoft.Contracts namespace in System.Core.

Looking at the Contract class reveals some custom exception types and a bunch of static methods that look surprisingly similar to what will be available in the CodeContract class in .NET 4.0.

What does this mean? It means that Microsoft internally was already using code contracts in .NET 3.5 but they weren’t available to the rest of us.

If you recall from my previous post, I mentioned that the CodeContract support in .NET 4.0 was based on the work done in Spec#. Looking at the disassembly of the Contracts class, specifically any of the methods that represent a post-condition evaluation, reveals a System.Diagnostics.ConditionalAttribute declaration with a value of “USE_SPECSHARP_ASSEMBLY_REWRITER”.

This attribute very clearly indicates that the code contract portions of Spec# had already made their way in to the .NET Framework with version 3.5. Not only that, but using the analyzer capabilities of Reflector show that the Contract class is being used by some of the Microsoft.Win32.SafeHandles and System.Security.Cryptography classes.

Running Reflector against the .NET 4.0 CTP reveals that the CodeContract class is very similar to the Contract class. It turns out that not only do all of the places that previously used the internal Contract class now use the new CodeContract class but a lot of new classes use it as well (including System.AddIn). The old Contract class is still present, but no longer used.

A few differences are that the new CodeContract class has more methods available and the Conditional attribute appears to have changed from USE_SPECSHARP_ASSEMBLY_REWRITER to CONTRACTS_PRECONDITIONS and CONTRACTS_FULL Conditional attributes.

The other important thing to realize is that the Assert and Assume methods are also marked with a DEBUG conditional which means that they will only appear in debug builds.