Thus, the problem was a combination of several restrictions and gotchas with code contracts. Hope this answer helps people like me just get started.
Firstly, Code Contracts has supported Visual Studio 2012 (any version other than Express) since the build of 1.4.50327.0, although you need to run devenv.exe /setup if your build is older than 1.4.50910.0. See the Release Notes for more details.
The first problem I encountered was that the "Cache Results" checkbox was checked in the "Static Validation" section of the contract code properties tab. This option is enabled by default, as well as SQL Server CE for storing cached data that is not installed on Windows 8, VS2012, or Code Contracts. Unfortunately, your program will continue to compile just fine, and you will have to manually iterate over the build result to see the error:
CodeContracts: xxx: Unhandled exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Data.SqlServerCe, Version = 3.5.1.0, Culture = neutral, PublicKeyToken = 89845dcd8080cc91' or one of its dependencies. The system cannot find the specified file.
Uncheck the "Cache Results" box to fix this problem, as well as installing SQL Server CE.
The second problem is that contract code violations are treated as warnings rather than error compilation . Even if you turn on βHandle warnings as errors,β your program will continue to compile and run. If you have a larger project with many warnings that you ignore, it can potentially be difficult to notice these new Code Contract warnings. In the demo video that I saw , these warnings were also reflected in the Visual Studio IDE (the call code had a blue underline), however, I donβt know, it looks like this is a behavior in Visual Studio 2012.
This design decision bothers me. If I define a contract in my code that the function should take an integer greater than 0, and I frankly pass in 0, this is an error. Not a warning. I broke this contract, simple and simple.
All in all, I would say that Code Contracts is extremely efficient and can potentially change the way you test software. MS Research has definitely done an excellent job. However, I do not think that he is really ready for the mainstream. Some improvement is required to work, it does not integrate into the Visual Studio build process, and is also rather slow. On small projects, it worked as expected, but when I connected it to a larger project, it took ten minutes to analyze the entire code.