Code contracts for .NET 3.5 messes up VS10's debugger

Question

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

Answer 1

have in mind, that the code contracts currently do not work with Post conditions & multithreading. limit the contracts to do only Precondition rewriting. that solved a lot of issues in our system.

Answer 2

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 nott o say that filing a bug is not for a good cause, jsut 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 :-)