This is something we've talked about, but haven't started work on. It might even be that a component could register its contracts with a component framework so that if there's a failure, the framework could check the contracts and assign blame properly.
(Not as good as your idea of proactively preventing the problem, but another use of the same facility.)
Yes, the idea is that the bubbles (adornments) should show up when you are writing an override of a virtual method in a supertype or an implementation of an interface method and you are going to inherit a contract from the overidden method or the interface
method (respectively). Otherwise you might not be aware of it.
This is a fine place to ask, but in general we will be monitoring the forum more, so please use that for questions. (https://social.msdn.microsoft.com/Forums/en-US/codecontracts/threads/)
But yes, you can have preconditions on any method, not just constructors. In the video, we just ran out of time before we could write a method more complicated than ToInt() and since that one had no parameters, it didn't make any sense to put a precondition
Thanks for all the great comments! I'm glad you pointed out our limitations as comedians: Nikolai and I had been just about to quit our day jobs and head back to LA to make our names in the comedy clubs there. I guess we'll just have to stay at MSR and
work on Contracts and Pex!
I just wanted to point out that we have a web site for the project:
https://research.microsoft.com/contracts. That page contains a link to an email alias we've set up: codconfb _at_ microsoft _dot_ com. You can use that to send specific comments about the tools and the many bugs I'm sure you'll find in our tools. The alias
is unfortunately one-way. We can see the mail you send to it, but you can't join the alias. We are working on a separate forum for the Code Contracts project, but it isn't set up yet.