DevLabs: Code Contracts for .NET

Click & Solve » DevLabs: Code Contracts for .NET

Click & Solve » DevLabs: Code Contracts for .NET — Tue, 24 Feb 2009 01:47:30 GMT

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

Preview of Code Contract Tools Now Available [Melitta Andersen]

BCL Team Blog — Tue, 24 Feb 2009 02:02:59 GMT

In my Introduction to Code Contracts post, I mentioned that the tools to enable runtime checking and

re: DevLabs: Code Contracts for .NET

Kris — Tue, 24 Feb 2009 04:07:38 GMT

A while back I heard Microsoft was releasing Spec# - something along the lines of CodeContracts. I believe it was a research project. Whatever happened to it? Or was that completely different from CodeContracts?

re: DevLabs: Code Contracts for .NET

Justin James — Tue, 24 Feb 2009 08:17:03 GMT

This looks a lot like Spec#. Is this indeed a release of Spec#? Or is this in parallel to that project? I am going to announce this item next week on TechRepublic, and I would love to have the correct information.

Thanks in advance!

J.Ja

re: DevLabs: Code Contracts for .NET

Jeremy Gray — Tue, 24 Feb 2009 09:04:47 GMT

Just what we need, another dev labs project that requires a Team System -level VS 2008 license! Sigh.

re: DevLabs: Code Contracts for .NET

Keith J. Farmer — Tue, 24 Feb 2009 10:16:42 GMT

@Jeremy: If you go the the site, you'll also find installers for the other (non-Express) SKUs under non-commercial license.

re: DevLabs: Code Contracts for .NET

Chris Varley — Tue, 24 Feb 2009 12:06:26 GMT

If you want something that does almost the same thing with very similar syntax, ContractDriven.NET 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 (no Team System licence required!) :-)

best regards,

Chris.

re: DevLabs: Code Contracts for .NET

bw — Tue, 24 Feb 2009 15:28:10 GMT

It's about time we had support for this, thanks.

re: DevLabs: Code Contracts for .NET

Jason P Sage — Tue, 24 Feb 2009 16:06:31 GMT

This is range checking, this is more work. I think this is silly and a waste of money and developer time.

Developers should already be testing input/output parameter validity and have integrated methods from returning error conditions.

This locks your code in ways that slow productivity. How? Let's change the code to handle a larger numeric datatype... int32 to int64. Edit the range check - an additional line of code. Test. Yay! Wait... Now I need to go into this tool and tell it of my changes.

Sorry folks - I like one stop shopping and this is hardly that.

--Jason P Sage

re: DevLabs: Code Contracts for .NET

Justin James — Tue, 24 Feb 2009 17:44:57 GMT

I am fairly certain that this is closely related to Spec#... 2 of the folks who are/were on the Spec# project are on the Code Contract project! Still, I would like some positive confirmation of this for when I write my article.

Thanks!

J.Ja

re: DevLabs: Code Contracts for .NET

Mark Gordon — Tue, 24 Feb 2009 17:46:48 GMT

Total agree with you @Jason P Sage! There are many "holes" in VS that need mending for Microsoft to be worried about fluff add-ons.

re: DevLabs: Code Contracts for .NET

.NET 4.0 Dev — Tue, 24 Feb 2009 18:06:47 GMT

Hi Soma,

I am sure your team is busy finalizing .NET 4.0 Beta 1, so could I make a suggestion ...

Traditionally, Microsoft forbid developers publicly deploying apps based on early beta versions of .NET (prior to the go-live licenses, which come with the very late betas in the cycle).

Following in the footsteps of MEF, ASP.NET MVC and other recent releases from Microsoft, I think it would be great if with .NET 4.0 Beta 1 you would allow public deployment, with the clear proviso that the beta is, well, an early beta and not supported and used at developers' own risk.

Obviously developers who are working on software for nuclear power stations, avionics or Wall Street should not be deploying apps based on the betas, but lots of developers are working on smaller, less critical projects, and start learning the new APIs with simple demo apps, and it is not a major problem if they crash from time to time or have other bugs. You will get significantly more interest in Beta 1 among developers if they can start using it for smaller/demo apps straight away. If they have to wait a year for any deployment options, then the response will be much more muted.

re: DevLabs: Code Contracts for .NET

.NET 4.0 Dev — Tue, 24 Feb 2009 18:09:08 GMT

Hi Soma,

In a previous blog comment regarding the Office Ribbon UI licensing:

http://blogs.msdn.com/somasegar/archive/2008/11/12/net-fx-4.aspx#comments

someone posted:

"Soma, the ribbon is currently covered by the bizarre 'Office UI Licence' (which was presumably accidentally excreted in the dying spasms of 'old MS'). Can you reassure us that the absurdity of the UI licence isn't going to encumber the use of WPF4?"

to which you replied:

"We hear your feedback on the license issues. The .NET FX team is keeping that in mind to ensure you don't encounter these issues with WPF4."

Could you confirm that the "new" Microsoft has won this battle and the Office UI License definitely won't be needed for .NET 4.0 users?

re: DevLabs: Code Contracts for .NET

Judah Himango — Tue, 24 Feb 2009 18:34:24 GMT

For those wondering what the relationship between this CodeContracts library and Spec# is, yes, Microsoft changed Spec# from a language into a library that can be used from any language: CodeContracts.

This library works in co-ordination with Microsoft's Pex, the white-box static analysis tool that can generate unit tests for you.

The guy working on Spec# is now working on this CodeContracts. He gave a talk on this at the last PDC.

re: DevLabs: Code Contracts for .NET

Mike Barnett — Tue, 24 Feb 2009 21:51:50 GMT

There have been some questions about the relationship of Spec# to the current Code Contracts project. The Code Contracts work is definitely a spin-off from the Spec# project. We learned many things in our work on Spec# --- two of the most important being that it is important to fit into existing languages and that providing total soundness is too burdensome. Spec# continues to be an important research vehicle for us. We are hoping that the current project will provide immediate and practical benefits for working programmers.

In a nutshell, Spec# was an extension to C# (v2.0) that provided the same design-by-contract features of method pre- and postconditions and object invariants. It also had a non-null type system and provided support for a sound treatment of object invariants. You can find out much more about it at our web site: http://research.microsoft.com/specsharp.

re: DevLabs: Code Contracts for .NET

Mike Barnett — Tue, 24 Feb 2009 21:59:43 GMT

In case my previous post was too short and you'd like some more details, here's some comments by Wolfram Schulte:

Spec#’s research focus is to understand the meaning of object invariants in the presence of inheritance, call backs, aliasing and multi-threading. Spec# uses a source level rewriter to weave the contracts into the code, and it uses verification condition generation and a theorem prover for static verification of Spec# code. But dealing soundly with all the complex issues around maintaining object invariants has a price: verification becomes non-trivial. That’s why Spec# also needs an ownership discipline to know which objects may alias or cannot alias each other.

Code Contracts is the result of learning from Spec# what works and what doesn’t. Unlike Spec# Code Contracts are language agnostic, and thus work across all of .NET languages, from VB to C# to F#. The rewriter works on MSIL and thus had no dependency on particular compilers. Its static analysis engine uses abstract interpretation, which is much faster and more predictable than verification; furthermore abstract interpretation infers loop invariants and method contracts, which helps in adoption and ease of use of Code Contracts.

re: DevLabs: Code Contracts for .NET

Mike Barnett — Tue, 24 Feb 2009 22:11:15 GMT

And because I keep hitting "Submit" instead of thinking a few more minutes, here's another thought... We want to encourage you to repeat any questions/comments on our forum that is dedicated just to the Code Contracts project: http://social.msdn.microsoft.com/Forums/en-US/codecontracts/threads/.

re: DevLabs: Code Contracts for .NET

Beren Camlost — Tue, 24 Feb 2009 23:15:48 GMT

Just a minor comment, the example on the "The Binary Rewriter" section is not a good use of Design by Contract. It is indeed a validation on runtime. Design by Contract ensures that the software is correct according to the specifications not to perform validations. I know that it is just an example but it could be confusing to someone who is not aware of the main concepts.

re: DevLabs: Code Contracts for .NET

fschwiet — Wed, 25 Feb 2009 01:25:40 GMT

Ahh, DbC, brings back memories. Now the hip thing is TDD. They achieve similar goals, with different strengths and weaknesses. I do appreciate having this additional tool available as an option.

(and personally I prefer DbC over TDD)

re: DevLabs: Code Contracts for .NET

Mohamed Meligy — Wed, 25 Feb 2009 13:34:59 GMT

This is great. I have been following any related news and stuff for long.

But... Why does it require VSTS not just VS Pro ??

Code contract is out

LA.NET [EN] — Wed, 25 Feb 2009 21:29:13 GMT

Check the announcement here and the site is here .

re: DevLabs: Code Contracts for .NET

Steven — Wed, 25 Feb 2009 21:33:05 GMT

@Chris Varley. I'm sorry, but you can't compare ContractDriven.NET with .NET Code Contracts. I know what I'm talking about, because I've build a 'contract' framework like you did (www.codeplex.com/conditions). However, Code Contracts is about COMPILE TIME verification. That is something we both can not offer in our frameworks. For this reason Code Contracts is the bomb :-).

I truly hope Code Contracts will not only be included in the team editions of Visual Studio 2010, but also in the professional edition of VS 2010. While I can understand Microsoft trying to get their investments back; releasing Code Contracts to the masses would have serious impact on the quality of the software .NET developers will write. This would reposition .NET as a whole!

Code contract is out

ASPInsiders — Wed, 25 Feb 2009 22:25:10 GMT

Check the announcement here and the site is here .

Somasegar's WebLog : DevLabs: Code Contracts for .NET

DotNetShoutout — Wed, 25 Feb 2009 22:45:29 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

Code Contracts for .NET

Dr. Z's Blog — Wed, 25 Feb 2009 23:06:55 GMT

Check out Somasegar's weblog to find out this newly added feature for .NET developers.

DevLabs: Code Contracts para .NET

Blog de Soma en español — Thu, 26 Feb 2009 04:48:32 GMT

Publicación del inglés original : Lunes, 23 de febrero de 2009 14:11 PST por Somasegar En octubre del

re: DevLabs: Code Contracts for .NET

Castdev — Thu, 26 Feb 2009 17:13:40 GMT

Is there any solution to use Microsoft.Contracts.dll in a VSTS 2008 Silverlight 2 project (converting the assembly into a silverlight compatible one seems to be unsuccessfull) ?

re: DevLabs: Code Contracts for .NET

Robert Claypool — Thu, 26 Feb 2009 20:29:39 GMT

@Steven

I agree. Limiting access to TeamSystem users would dampen the effect it can have. More verifiable code benefits and strengthens the entire platform, so I hope that Microsoft releases this for everyone to use.

re: DevLabs: Code Contracts for .NET

Mike Barnett — Fri, 27 Feb 2009 00:08:26 GMT

In response to "Castdev" about Silverlight: we will try it out and make sure it works for Silverlight. (Sorry that we didn't do that already.) I would encourage you to start a thread over on the Code Contracts forum: http://social.msdn.microsoft.com/Forums/en-US/codecontracts/threads/ and then we can track this issue.

re: DevLabs: Code Contracts for .NET

Cardin — Fri, 27 Feb 2009 13:14:21 GMT

So basically this is compile-time range checking? Kinda like assert() isn't it?

re: DevLabs: Code Contracts for .NET -> images not displaying....

Kiruthik — Sat, 28 Feb 2009 21:56:14 GMT

Soma,

I couldnt see the Images in this post. I could see that you have added some images in between your post through HTML, but its not visible to the browser. I have tried in couple of machines in IE & FF.

re: DevLabs: Code Contracts for .NET

Somasegar — Sun, 01 Mar 2009 05:31:24 GMT

Hi Kiruthik,

It looks like the server that is hosting the images is down. We will try to get it back up soon. Thanks for the note.

-somasegar

Design by Contract – O Retorno (?)

Arquitetura em Pauta — Sun, 01 Mar 2009 16:07:55 GMT

Creio que foi Bertrand Meyer, o autor da linguagem Eiffel, quem primeiro falou sobre Design by Contract

re: DevLabs: Code Contracts for .NET

Mark Gordon — Mon, 02 Mar 2009 20:50:01 GMT

@Mike Barnett you wrote

"Spec#’s research focus is to understand the meaning of object invariants in the presence of inheritance" ...

While I'm NOT diagreeing with you at all ... I only want to point out the inheritance part of your comment is not really relevant in the context of Visual Studio in this regard: The class browser which should be work horse for true inheritance based programming models is not useful and can't subclass UI controls. There are numerous challenges subclassing UI controls that need to be worked around even if you hard code the classes. WPF UI controls, best practices, suggests not subclassing UI controls. I could go on especially on the web side of things which is more screwed up then desktop development (including MVC which I was hoping would address many of these issues). The bottom line without sublcassing you don't have inheritance!

While I'm a very strong advocate for "true" OOP standards including inheritance, Microsoft redefines patterns/standard as they see fit to overcome short comings in their VS dev tools. This is much easier then actually the fixing the issues!

Personally I wish all the problems with inheritance where addressed in VS before implementing additional features like this and I don't understand why they can't be given they got this right in 6.0 tools sets for the most part. That is what is so frustrating we are forced to develop apps with poor implementations and bugs while Microsoft introduces more technology. Why can Microsoft get what they have released right then introduce new features on a solid foundation!

Preview of Code Contract Tools Now Available

CLR Team Blog — Wed, 04 Mar 2009 23:06:29 GMT

We’ve mentioned Code Contracts over on the BCL Blog a few times now, but never yet on the CLR Blog. Basically,

re: DevLabs: Code Contracts for .NET

Somasegar — Fri, 13 Mar 2009 05:28:20 GMT

Hi,

There has been a bunch of feedback about the restriction for this to work only with VSTS. The team is looking into and hopefully we will get a chance to fix this in a subsequent update.

-somasegar

re: DevLabs: Code Contracts for .NET

Green Williams — Wed, 25 Mar 2009 23:13:32 GMT

Non-sense. There is nothing pioneering in this. Even the author admit this prior to talking about it. Somaasegar forgot that Microsoft Research does not exist to do "Research" and "Innovate/invent" but to copy (Microsoft has invented innovative techniques like AJAX BUT never an innovative product.) This feature is just Microsoft copying someone else. I am not criticizing because I use Microsoft in my Software Engineer tasks. I just hate it though when people attach innovation to Microsoft and "Microsoft Research".

re: DevLabs: Code Contracts for .NET

Somasegar — Wed, 25 Mar 2009 23:32:26 GMT

Hi Green,

I have never been a a part of MSR (Microsoft Research), but from my perspective I see a fair amount of innovative ideas coming out of MSR - we have successfully brought to market some of the ideas from MSR in our products and MSR continues to be a substantial contributor in terms of publishign papers in SIGGRAPH and other leading forums.

-somasegar

re: DevLabs: Code Contracts for .NET

Chris Varley — Mon, 27 Apr 2009 21:40:12 GMT

@Steven. Hi Steven, I do agree with you. I was just offering an alternative to those who do not want to pay for the compile time checking as part of the Team System licence. ContractDriven.NET does NOT allow you to do compile time checking. However it does allow you to write runtime contracts in to your code to improve your codes readability, maintainability and runtime reliability (and it supports invariant conditions which many of these types of library do not.) ContractDriven.NET can also be used with the standard .NET CLR (so supporting any .net language and even works on works on Linux via Mono).

I like your fluent interface for your conditions BTW.

High Test Coverage Ratio is a good thing, Anyway!

Patrick Smacchia [MVP C#] — Sun, 07 Jun 2009 12:11:10 GMT

Normal 0 21 false false false FR X-NONE X-NONE I heard several times that high test coverage ratio, and

re: DevLabs: Code Contracts for .NET

Mark Stewart — Fri, 24 Jul 2009 09:17:54 GMT

using your blog this victim of Canadian incompetance found a trial download link, but certain ew2 issues and ew3 upgrade issues have gone to Connect. A million shining stars to Somasagar for keeping our world on top of ... that world.