title: Code Contracts - nice, on the edge, but not ready for prime time?
body: <p>I got really captivated by code contracts introduced in .NET 4 (though with the help of DevLabs). But one fine print cooled me off quite a bit. Here is what it says:</p>
  
  <ul>
  <li>There is currently no workaround the problem when postconditions are called outside of lock in a thread-safe method except for not using them.</li>
  <li>.NET relies on a binary rewriter thus making the build slower.</li>
  <li>Using code contracts may also incur a runtime performance hit.</li>
  <li>Can't be used for security-sensitive checks because they can be circumvented at runtime by handling the ContractFailed event.</li>
  </ul>
  
  <p>The biggest for me is the first one. I don't know if anyone write single-threaded apps anymore. So if code contracts are not able to support multi-threading, I don't see much use of them. Or maybe I shouldn't be stressed too much about that because postconditions are for asserting the internals of the method itself, which can be unit-tested. </p>
  
  <p>BTW, I haven't found anything and I didn't try to disassemble my code to see where preconditions are injected. I suppose in a simple method when lock() goes first, it's simple to inject checks right after it but in a rather complicated method, when locking occurs somewhere in the middle, it may be an issue. Or if some other mechanisms other than lock() are used.</p>