I’ve recently migrated a lot of manual precondition testing and exception throwing with code contracts. Instead of upgrading to .NET 4, I’ve been using the Microsoft.Contracts.dll assembly so I could stick to .NET 3.5 a bit longer (this is a library that is used both by .NET 3.5 and .NET 4 assemblies). I’ve set up the contracts rewriter in Visual Studio 2010 and the contracts work just fine.
However, since I’ve done that switch, I’ve noticed that the debugger acts funny in methods with contracts, especially in classes with a ContractInvariantMethod. The execution cursor doesn’t seem to always match the highlighted line, some breakpoints fail to be hit and I’ve had a method in which the debugger couldn’t tell the local variable names and would show stuff like CS$1$0000. This is in debug builds.
Are there known issues about using the code contracts in Microsoft.Contracts.dll in .NET 3.5 through VS10?
Do similar issues arise with the code contracts in .NET 4?
[Edit] This question lead me to create a bug on Microsoft Connect: https://connect.microsoft.com/VisualStudio/feedback/details/573983/code-contract-rewriting-messes-up-local-variable-names-in-iterator-methods-while-debugging
I hope you know what contract rewriting means—extra code generated on the fly which doesn’t have any source code for compiler to latch on. With CLR having so many different elements, there’s quite a number of things that debugger either won’t do at all or will get confused and only things which are full blown language features with wide impact get the budget for complete debugger support. Like lambda expressions for example.
Which is not to say that filing a bug is not for a good cause, just that you shouldn’t expect anything to turn better when you are using an aspect which is not even fully developed yet. Being early adopter always has that kind of cost, but also the bragging rights 🙂