Search

Make data contract static checking available in Professional Edition by David A Nelson

Active

209
1
Sign in
 to vote
Type: Suggestion
ID: 481327
Opened: 8/6/2009 8:11:43 AM
Access Restriction: Public
0
Workaround(s)
In Visual Studio Beta 1, static checking of code contracts is only available in Team System edition. Limiting a feature which has such potential to dramatically improve the quality of applications running on the .NET platform to just the very top tier of development tools leaves it out of reach for the majority of .NET developers. Since design-by-contract has nothing to do with team-based development, but is in fact a feature that is useful to all professional developers, the full feature set of Code Contracts in .NET should be available in Professional Edition.

Static checking is the core of DbC. Without it, the entire Code Contracts library just becomes a fancy way of throwing ArgumentExceptions. As long as static checking is only available in Team System, DbC will never become mainstream in .NET development. This would not only be a travesty for the .NET community, but also an insult to the Code Contracts team that has worked so hard for so long to bring this great feature to the framework.

Please see the following forum thread for more discussion about this critical issue: http://social.msdn.microsoft.com/Forums/en-US/codecontracts/thread/459bdcbe-8af2-4781-b1fa-eec1c9d79a52. I will also include a few representative quotes:

"In my company...we evalute actually Spec# and it works fine with any versions of VS2008 ...I don't understand why a Team System required (not for PEX or Spec#) while the foundation seems to be the same like spec#".

"This feature will give .NET an huge advantage over it's competitors. But this will only happen if we can make it mainstream...If you don’t do it for the software industry, then think about the number of organizations that will possibly move to .NET (and therefore buy Visual Studio) because of Code Contracts."

"I'm a professional developer who uses VS Professional. Most of my clients use VS Professional, not TS. I simply will not be able to adopt your implementation of code contracts unless it's available in VS Pro..."

"It is a shame though that MS is not going all the way in assisting all paying VS developers in improving the quality of their code in this pretty elegant way. Team System is not worth the price tag and tends to be overkill for small/medium size organisations."

"Each of our developers has Visual Studio 2008 Pro with MSDN Subscription Pro. At $2000 a pop, I would expect to be able to use Code Contracts without using TFS."

"VSTS is very expensive. Where I work...we are not big enough to justify or afford using VSTS as our dev tool...Yet we pay big money to get the "Professional" package and we build big and complex software with those tools. Being able to statically assert the correctness of our software can only improve the quality and means less bugs disovered when we're live on the production server...I think all those features are very useful to any "Professional" software development and I don't see why they would belong to a "Team System" only. They have nothing to do with team work, only code quality. The better the .NET code in the wild is, the more the platform will shine."

"Of course significant investment has been put into creating a unique and valuable product. This investment deserves reward. However, the Professional edition of Visual Studio is an expensive product - its price point creates the justifiable expectation that it should contain the latest state of the art professional development tools."

"To my mind, MS dropped the ball on unit testing back with VS2005. By restricting it to VSTS at the time, they basically handed the market to NUnit on a plate. Making it available in Pro for VS2008 was too late - they'd already lost developers to NUnit. If MS wants Code Contracts to really change the industry, they've got to put it in the hands of the majority of developers...Can you imagine what would have happened if everyone had got LINQ in VS2008, but only TS developers could use query expressions instead of dot notation? Please, please revisit this decision."
Details (expand)

Version Currently Used

Visual Studio 2010 Beta 1
Operating System Currently Used
Windows XP
Suggestion
Make static checking of Code Contracts available in Visual Studio 2010 Professional Edition.
Benefits
Faster Development
Improved Reliability
Other (please provides details below)
Other Benefits
Mainstream acceptance of Code Contracts in the .NET platform

 

You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey. [Details]

 

File Attachments
0 attachments
Sign in to post a comment.
Posted by GarenP on 8/21/2010 at 5:18 AM
Putting something that is expected to be a native, built-in feature of a programming language (i.e. Contracts) only in the "Team" editions strikes me as being akin to disallowing people from using exception-handling unless they are in a "Team" and buy the more expensive SKU of VS.

It's absolutely not a TEAM-oriented activity and should not be viewed as "value added" but something worthy of being in the language proper.
Posted by Jacob Page on 8/11/2010 at 2:38 PM
At the very least, the data contract static checking should be available as a purchasable plug-in. Some of us are not interested at all in things like Team Foundation Server, so buying VSTS seems like a big waste of money despite it having the highly-anticipated data contract static checking.
Posted by TheGhostJW on 5/30/2010 at 1:41 AM
This explanation is rubbish.
Please refer to the comment by jzabroski. (S)he sums up the situation perfectly.
Posted by Roy Dictus on 3/1/2010 at 11:03 PM
I see Code Contracts as an important part of code quality assurance, much like unit testing. Therefore, I think it is essential to have this feature available in as many Visual Studio versions as possible.

I also hope that when the .NET Fx 4.0 goes RTM, Code Contracts will still be in mscorlib, and that the CC library for .NET Fx 3.5 will be part of the next SP instead of a download from DevLabs. As long as Code Contracts are a part of DevLabs, many companies will not want to use it, seeing it as an incubation project rather than as a tool they can use today.
Posted by Dave Sexton on 1/29/2010 at 5:56 PM
"It keeps the code analysis story consistent, in that the static analysis tools require VSTS."

The problem with this mode of thought is that static analysis tools like FxCop and StyleCop do not require code modifications. This is a very important difference. Code Contracts requires us to take precious time to add contracts to our code before they will be useful.

The result, without static analysis, is mediocre at best. For one thing, my program might not throw exceptions at runtime during testing but throw exceptions in production code because of missed contracts. I can get this benefit without code contracts. The real gain is in the static analysis.

Furthermore, without static analysis we lose immediate feedback on how we can improve our code's design, much like not being able to execute FxCop and StyleCop from within the IDE, but with one major difference: we have still taken the time to add contracts to our code. This would be like adding the code analysis suppressions without the benefit of code analysis.

What is the real value in replacing if...throw statements or using code contracts instead of adding new ones without static analysis?
Posted by wesmcclure on 1/27/2010 at 8:36 AM
Design by contract is a fundamental OOP issue that should be baked into the language. It is as important as the type system itself in defining the semantics of a class. Would anyone ever dream of charging for static type checking? If not, then why would anyone dream of charging more for static contract checking? The two concepts go hand in hand, and static analysis can go a long ways to help produce correct software, to catch bugs earlier.
Posted by John Zabroski on 12/1/2009 at 8:52 AM
"It keeps the code analysis story consistent, in that the static analysis tools require VSTS."

In that case, please remove the Errors window with "Warnings" notification from Visual Studio. Also, please remove from the SDK the csc.exe compiler as it presently stands, because it has command-line options for producing and/or suppressing static analysis feedback such as compiler Warnings.

You're apparently not aware of the "consistency bug" in all previous releases of Visual Studio that shipped with compilers that supported static analysis and provide useful Warnings to users, and this inconsistency must be resolved before you release .NET Framework 4. Please also release Service Pack releases for all past versions of Visual Studio, and remove all static analysis from all Microsoft sponsored compilers, unless they are using Team Suite edition.
Posted by Luke Breuer on 12/1/2009 at 8:46 AM
Microsoft, do you or do you not want higher code quality to be associated with .NET and Windows? I do not see how the question is any more complicated than that.
Posted by John Leidegren on 11/20/2009 at 2:27 AM
I don't get it, the static analysis of code contracts is what makes it intresting in the first place. Restricting static analysis to VSTS is literaly the same as giving the hungry man food, then trying to explain to him that he cant eat it.
Posted by Belinda H.1 on 10/30/2009 at 12:06 PM
Our team just doesn't have the budget for the full TS versions. Why should we be penalised, especially when it comes to such essential areas such as debuggin, ensuring reliability and code quality?
Posted by abhijit gadkari on 10/28/2009 at 9:17 PM
When I first saw contracts i had my aha moment - in fact, i ended up posting up a code project article on this - http://www.codeproject.com/KB/dotnet/CodeContract.aspx

And now I am feeling bad as it will be available only in VSTS - such a bad decision and explanation for this is equally ridiculous...
Posted by Daniel Smith on 10/21/2009 at 1:48 AM
I see the answer to the problem seems to be the renaming of the product from Team Suite to Ultimate :-/
Posted by Daniel Smith on 9/30/2009 at 6:18 AM
This is indeed pretty shameful practice. There are many requests on Connect for code quality and reliability features to be made available in all editions, and it's to the detrement of developers, the industry, and end users alike. MSFT can't possibly be proud of this stance.

"It keeps the code analysis story consistent, in that the static analysis tools require VSTS."

Just because you're consistent in disappointing and alienating your customers, doesn't make it acceptable!
Posted by David A Nelson on 8/17/2009 at 11:59 AM
That is...unfortunate. I guess all I can say is that it is an irresponsible and short-sighted decision by Microsoft to sacrifice the long-term health of the Windows ecosystem in order to squeeze a few extra bucks out of software developers for the IDE. How anyone - development manager, marketing consultant, or accountant - could run those numbers and come to this conclusion is beyond me. Frankly, as a professional developer at a relatively small company, I am getting pretty tired of Microsoft denying the most important developer features to their "Professional" development environment. I would have thought that a software company that has been around as long as Microsoft would understand that the best thing it can possibly do for its own bottom line is to strengthen the community of developers which make its ecosystem possible, and in turn enable them to strengthen that ecosystem and contribute to the success of Microsoft across the world at large.

It is disappointing to discover that lesson has still not been learned.
Posted by Microsoft on 8/12/2009 at 5:49 PM
Hi CommonGenius,

Thanks for taking the initiative to bring this issue over from the Code Contracts forums to Connect. Those of us on the feature do understand that having the static analysis tools outside of VSTS would allow Code Contracts to more rapidly gain mainstream acceptance, even though just the runtime checking is also very useful. As you know, we lift the restriction on runtime checking to help make the feature more accessible, but the restriction on the static analysis tool stands for this upcoming release. It keeps the code analysis story consistent, in that the static analysis tools require VSTS.

I'm going to leave this issue open so that we can continue to get votes and comments on it. We'll also keep watching the forum, so that we have more data the next time we consider this issue, which we will do for every release.

Thanks,
Melitta
Base Class Libraries Team
Posted by Microsoft on 8/7/2009 at 2:13 AM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement