Preview of Code Contract Tools Now Available [Melitta Andersen]

Preview of Code Contract Tools Now Available [Melitta Andersen]

  • Comments 11

In my Introduction to Code Contracts post, I mentioned that the tools to enable runtime checking and static analysis were not included in the .NET Framework 4.0 CTP.

Today we are releasing a preview version of the Code Contracts tools on the DevLabs site.  DevLabs is a site for getting preview releases of innovative new projects for developers out to the community.  You can read more about it on Soma’s introductory blog post.  The specific Code Contracts page on DevLabs can be found here.

The tools include a binary rewriter to enable runtime checking, a static checker, a new project pane for VS projects, and an updated copy of the Code Contract library.  For more details on what these are, you can check out the Code Contracts page, which includes an overview, a video on how to get started, an FAQ, and other useful information.  You can also check out the documentation (PDF), or get an overview in Soma’s recent post on Code Contracts.

This current release is targeted at Visual Studio 2008 Team System and can be used for commercial development.  The academic release that can be used for non-commercial use on any Visual Studio 2008 edition except Express can still be found on the Contracts page on the Microsoft Research site.

This new release also comes with more ways to provide feedback and get answers.  In my last post, I mentioned the Code Contracts thread on the Pex forum.  Now Code Contracts has its own forum.  So please go try out these new tools and tell us what you think.

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

  • 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...

  • 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.

  • 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.

  • 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.?

  • 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?

  • 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.

  • 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.

  • @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"...

  • 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.

  • 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

Page 1 of 1 (11 items)