Preview of Code Contract Tools Now Available [Melitta Andersen]

Click & Solve » Preview of Code Contract Tools Now Available [Melitta Andersen]

Tue, 24 Feb 2009 03:05:13 GMT

PingBack from http://www.clickandsolve.com/?p=13459

re: Preview of Code Contract Tools Now Available [Melitta Andersen]

David Nelson — Tue, 24 Feb 2009 08:08:37 GMT

Melitta,

Do you know why the "academic" version works on any non-express SKU, while the "commercial" version only works on Team System? My organization uses Professional, which means that as of now we are prevented from using Code Contracts in any of our applications, for no good reason that I can see.

Someone who were inclined toward conspiracy theories might think it was yet another way to force people into buying a more expensive SKU that they don't need...

re: Preview of Code Contract Tools Now Available [Melitta Andersen]

Paul — Tue, 24 Feb 2009 11:39:26 GMT

Am I correct in understanding that Code Contracts.NET is not supported for Visual Studio 2008 Professional edition? If so, please provide the motivation behind this.

re: Preview of Code Contract Tools Now Available [Melitta Andersen]

Chris Varley — Tue, 24 Feb 2009 12:20:22 GMT

Hi,

You don't need to but a more expensive SKU. ContractDriven hosted on CodePlex.

(http://www.codeplex.com/contractdriven) provides a very similar syntax and has the benefit that it's both Open Source and free.

It does not currently have any static analysis but it works in VS 2008.

re: Preview of Code Contract Tools Now Available [Melitta Andersen]

Jonathan Pryor — Tue, 24 Feb 2009 17:34:28 GMT

Haven't tried code contracts yet, but I did read the PDF documentation.

That being said...is it too late to change the design?

What I find...troubling, or at least bizarre, is the implicit semantic change in argument validation.

Since before .NET 1.0, validation has been manual, yes, but it has also been exception based:

public void Foo(string s) {

if (s == null) throw new ArgumentNullException("s");

...

}

Code contracts present a nicer interface to do the same thing:

public void Foo(string s) {

Contract.Requires(s != null);

...

}

Personally, I like the syntax.

However, from reading the documentation, the resulting runtime behavior effectively results in:

public void Foo(string s) {

if (s == null) Environment.FailFast("s != null");

...

}

So if we pass an invalid argument, we kill the process with extreme prejudice.

Isn't that just a little...excessive?

Furthermore, at least on .NET 2.0, Environment.FailFast() doesn't provide a stack trace for the error. So not only does it kill the process with extreme prejudice, it doesn't provide the developer any easy way to find where they went wrong. (On a slightly related note... What are you thinking?!?!?!)

Fortunately this can be changed by using the Contract.ContractFailed event or using the RuntimeFailureMethods type listed in §7.1, but I find this inadequte, as e.g. RuntimeFailureMethods.Requires() wouldn't be able to distinguish between throwing an ArgumentNullException() vs. another ArgumentException() subclass (unless you resort to parsing the condText string, which is error-prone).

So is there any chance the default behavior of Contrace.Requires() could be changed to follow "traditional" argument validation principals -- using useful Argument* exceptions, etc.?

re: Preview of Code Contract Tools Now Available [Melitta Andersen]

Jeff Lewis — Tue, 24 Feb 2009 22:46:45 GMT

No disrespect intended, but I've been digging through this thread right from the RSS feed posted in Channel 9 today and several people have asked 'why does the commercial license only work with Team Studio while the non-commercial license work with the other versions?'

None of the responses so far are actually answers. They either point to other posts which essentially say the same thing: commercial needs TS and non-commercial works on everything else but Express - which we KNOW already or else we wouldn't be asking the question.

Pointing us to the 'freeware' version isn't an answer either. It's trying to dodge the answer. If the freeware version was a good as the full version, you wouldn't need a license.

The obvious answer is: this forces you to buy TS. That's actually ok - it's Microsoft's product and they have every right to try to tie a new feature to a specific level in order to improve sales of that level. But that will also seriously depress uptake on that feature.

I'm not in a team for most of my development, and so any of the team products are way over the top for me. On the other hand, I do produce commercial products. Which means that Contract library as provided by Microsoft isn't going to a part of my development process.

Perhaps it would be better to sell these add-ons individually and let us decide which pieces we want?

The VSTS Restriction

Melitta Andersen — Wed, 25 Feb 2009 04:25:53 GMT

Code Contracts will ship as part of .NET Framework 4 and Visual Studio 2010. For Visual Studio 2010, we’re still working out the details regarding which Visual Studio products will have tooling support for Code Contracts. We think there is value in offering some level of tooling support in more than just the Team System products, but we haven’t finalized our plans.

As requested, this is the first preview release that can be used for commercial development (previous previews were for academic use only). Like most of the other technology previews on DevLabs (e.g. Pex and Chess), Visual Studio Team System 2008 is required. The reason for the Team System requirement is because we haven’t worked through the details of whether we could incorporate a technology in a particular product after having previously given it away with no restrictions first. The same issue would apply if we were to do something like Jeff suggested and sell the add-ons individually.

We’re glad to hear that there’s such a demand for this feature from customers. Your feedback will help shape our thinking as we finalize our plans for Visual Studio 2010.

re: Preview of Code Contract Tools Now Available [Melitta Andersen]

David Nelson — Wed, 25 Feb 2009 07:39:30 GMT

Melitta,

I am confused as to why, even in your comment, you seem to assume that these features will be included in Team System "by default", and will only be included in "lower" SKUs if enough "value" is found for them. Code Contracts are not a "Team" feature, they are a code feature. I am a professional programmer, and I use the Professional Edition. I don't use Team System because I don't need all of the "team"-oriented features that it provides (source control, task tracking, automated builds, etc). I could, however, make use of Code Contracts, just as much as any development team could.

There is no reason why Code Contracts should be considered a "team" feature. The fact that Code Contracts are only being considered for Team System indicates that Microsoft is using some other criteria for determining what goes in each SKU. If that is the case, the SKUs should at least be renamed to more accurately reflect their intended use cases.

re: Preview of Code Contract Tools Now Available [Melitta Andersen]

cnkz — Wed, 25 Feb 2009 08:26:38 GMT

@David (last paragraph actually): Absolutely. One thing that I never understood is why fxcop is only integrated in the team system SKU, and not in professional. Same thing now with code contracts - it seems. Looks like that the team system SKU should be the really called "professional"...

re: Preview of Code Contract Tools Now Available [Melitta Andersen]

Arman K — Fri, 27 Feb 2009 02:31:53 GMT

I can not but agree with Jonathan Pryor, even though I can understand why you are using FailFast, but I too would like to handle contract error like Jonathan says. I was thinking case when using Contract for WCF service, it will crash my service by FailFast and not providing me with the error.

re: Preview of Code Contract Tools Now Available [Melitta Andersen]

The Q — Mon, 09 Mar 2009 04:49:04 GMT

I would also like to see some improvements in regards to integration with WCF.

I wrote a blog post about getting the code contracts for a WCF service working on the client side, which was easier than I thought, but did nevertheless require some tinkering which the casual coder might not find all too intuitive.

Please have a look and let me know if there is a more convenient way of achieving this.

Blog post can be found at:

http://www.hexadecimal.se/2009/03/09/WritingRockSolidCodeWithCodeContracts.aspx