Team System only?
- My organization doesn't use Team System, we use Professional Edition. I don't understand why the "academic version" works with any version, but the "commercial version" (which is what we would have to have in order to use Code Contracts in our applications) requires Team System. Is this yet another way to try to force people into buying a more expensive SKU that they don't need?
Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
Answers
- I'm happy to announce that the runtime checking support will be available for commercial use for all Visual Studio versions. Look for a non-VSTS installer on the next release.
The static checker will remain tied to the Visual Studio Team System version for now.
Cheers, -MaF (Manuel Fahndrich)- Marked As Answer byManuel FahndrichMSFT, OwnerWednesday, March 18, 2009 4:09 AM
All Replies
- See the information in the BCL Team post:
http://blogs.msdn.com/bclteam/archive/2009/02/23/preview-of-code-contract-tools-now-available-melitta-andersen.aspx
Keith J. Farmer [Idea Entity] - I don't see a good justification for Team System in the post you referenced. The post says TS is required for the "current edition" and someone mentions an alternate project in the comments.What is the plan when .NET 4.0 / VS2010 rolls out? Will Code Contracts still be restricted to Team System SKUs?
Scott - We are working with management on lifting the team edition restriction. The issue is whether the company wants to charge for the feature in the future by attaching it onto the higher-end VS editions. Please let us know that you want the feature on non-team system editions.
-MaF- Proposed As Answer byManuel FahndrichMSFT, OwnerThursday, February 26, 2009 4:28 PM
- In my company (Air Liquide), we evalute actually Spec# and it works fine with any versions of VS2008 (expect express).
We are interesting by the agnostic language approach of Code Contracts but I don't understand why a Team System required (not for PEX or Spec#) while the foundation seems to be the same like spec# - The tools are powerful and I can certainly understand why you would want those in a high end SKU.I'd like to see mainstream acceptance of contracts, but the ideas and tools will never be mainstream if you restrict functionality to Team System. It could be that I'm not seeing the whole picture here - what does it really mean to require Team System? Would runtime analysis and checks require Team System? Would it be possible to offer the static analysis tools only in the high end SKUs, but make the runtime analysis and rewriter available in Pro?
Scott - If it's not something that can be mainstream, I probably wouldn't use it.
I'm not a player, I just code a lot... - Scott Allen makes a great point and I agree with him. I really like to see mainstream acceptance of design by contract and verification in the .NET world. For me this is the biggest improvement in .NET since.... since the framework itself. This feature will give .NET an huge advantage over it's competitors. But this will only happen if we can make it mainstream.
I'm a freelance developer and I assist the development teams of my customers with architecture, design and development in .NET. On a daily basis I'm trying to teach developers how to improve the quality and reliability of their software by using requirements, design and testing. All my customers use the professional edition of Visual Studio. I see a lot of bugs, that I know can be prevented when code was verifiable. Next year I’ll hopefully be teaching those developers how to use Code Contracts, because this will have a tremendous impact on the quality and reliability of the software they produce.
Please, please, please reconsider. We need Code Contracts and we need 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.
Visit my blog: http://www.cuttingedge.it/blogs/steven/- Edited byNET Junkie Tuesday, July 07, 2009 3:33 PMtypo
- Regarding your request for feedback:
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. We have been using TFS Workgroup Edition for several months. However, and it pains me to say this because I am a huge fan of Microsoft products, we are now abandoning TFS because it is so difficult to configure, is far from intuitive to use, and as soon as we add one more user, we've got to pay hundreds of dollars on top of the VS2008/MSDN cost. I am not a fan of open source products, but Subversion is a dream to setup as well as to use, and it is free.
Please consider not requiring TFS with Code Contracts.
Thank you.
Thomas Lunsford - While I understand that microsoft makes money by selling software products, and Code Contracts is definitely a nice one at that, I would very much like to see it in the non team system editions.
The classes for code contracts have been included in the .NET 4.0 runtime, and thus will be downloaded and installed with the other 150+ megabytes onto every user's machine whether we like it or not. It seems fundamentally counter to the overall philosophy of .NET (where even the command line compilers are free) to make it completely impossible to use these classes without a subscription to a product which is hopelessly beyond the means of many hobbiest programmers like myself.
While I really enjoy the static verification features, I can understand that they represent a significant technological investment by microsoft, and are worthy of the flagship product. As you have mentioned, they are meticulous, pickey, and not useful for large swaths of general development.
As a minimum proposition then, could you ensure that the code rewriter would be availaible in all versions? Many open source AOP projects already exist, it would not be long before an open soure rewriter came into being. Having two rewriters would merely confuse issues as different bugs gave differig results from the same code being analyzed.
I'd like to have it all, but if not, at least I'd like to have the rewriter.
Thanks
John Melville - > Please let us know that you want the feature on non-team system editions.
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 (and I would very much like to as none of my clients use Eiffel :) ).
Curt - http://www.codeneverwritten.com/ - I really don't understand why this feature is any different from any other useful framework that was open to any VS version.
Please tell me that this is not an experimental balloon to create a buzz around this. Currently, this is how it appears.
I hope I am wrong because, as mentioned by my predecessors, this could be quite handy.
Avi - +1 for VS professional only being req'd for .NET 4.0 code contracts support; this feature will not reach widespread adoption with a VSTS-dependency.
- If this is going to be a part of mscorlib in VS 2010, can it still be restricted for VSTS?
This is disappointing. - I'm happy to announce that the runtime checking support will be available for commercial use for all Visual Studio versions. Look for a non-VSTS installer on the next release.
The static checker will remain tied to the Visual Studio Team System version for now.
Cheers, -MaF (Manuel Fahndrich)- Marked As Answer byManuel FahndrichMSFT, OwnerWednesday, March 18, 2009 4:09 AM
- I am paying Visual Studio Professional user and would have been very disappointed by not having DBC support in all commercial versions of VS, so the latest announcement is a great improvement. 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.
- I agree with Gerke, it whould be a shame if it was not available. I would be willing to pay extra for the feature but I really have no need for the VSTS-edition. The only feature I'd use from VSTS would be the static checking and that is a big extra I need to pay for only one feature.
So: +1 for including static checking in the professional version (or add a version between professional and vsts without the team support). - I would also agree, as we are currently stuck using VS Pro. While Code Contracts for .NET sounds like a great idea (and I'll be looking forward to checking it out), it would be very useful to have the static checking also available as this sounds like it is a "check your code as you program" feature. Without this, it sounds like these checks are only performed at runtime. Hopefully testing tools would catch contract errors, but it would be nice to have these show up at or before compilation - for example when the developer or the build server compiles the code - and not before breaking a production system during a processing run.
- It's a great news that contracts will be available for all VS versions, but it's a shame that MS doesn't go the whole way and keeps the static checker tied to VSTS.
VSTS is very expensive. Where I work we are building MS-based software all the time, but we are not big enough to justify or afford using VSTS as our dev tool (although I'd love to have access to the DB edition of VSTS). Much of the feature-set of VSTS is targeted towards "enterprise-grade" "big team" development and I'm fine with that, it's not what we do.
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.
Not only us, but the whole .NET ecosystem would benefit from higher software quality.
MS did the same mistake in the past and it's a little bit insulting... How can MS be so wrong and think that "Professional" developpers don't need a testing framework (which was later downgraded from VSTS to Pro with the 2008 release, if I remember correctly)? Don't need code-coverage to go hand-in-hand with that testing framework? Don't need a profiler to find the bottlenecks in their code? Don't need code metrics to spot and fix poorly written methods? And now it seems we don't need to statically check if our assertions about our code are correct or not, either.
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. MS should be smart enough to understand what is best for .NET... - Thanks for these comments on the static checker use and that you want it in a version other than VSTS. Please keep the comments coming as this may help convince the decision makers on this issue.
Cheers, -MaF (Manuel Fahndrich) - I don't think bundling with Team System is appropriate from a technical or marketing point of view.Team System is an effective brand and somewhat effective product for providing team collaboration features. In my view static contract checking is a language and framework feature. Bundling it with Team System alone creates confusion about the Team System brand. On the other hand, Professional is also an effective brand that attracts knowledgeable and well-educated developers. Excluding the static checking from Professional is against the Professional brand's message.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.If you believe that you've truly advanced the state of the art beyond the price point of Professional edition then you should raise its price.Blake
I'm happy to announce that the runtime checking support will be available for commercial use for all Visual Studio versions. Look for a non-VSTS installer on the next release.
While this is a great step, but the static checker should at least be part of the Professional Version. Professional in itself is not cheap, yet going to VSTS is much much more expensive and which our company cannot justify buying. We have a team of 10 developers. If we were to buy VSTS for each dev, the cost would be at a minimum $50,000+. There is no way our company could justify such a cost compared to buying professional. And so VSTS is limited only to large corporations and not to the small to mid level companys. So Microsoft is saying only large companys will have access to static checker. Forget the little guy.
The static checker will remain tied to the Visual Studio Team System version for now.
Cheers, -MaF (Manuel Fahndrich)Please Microsoft, add static checker to VS.Net Pro- I'm wonder if anyone be able to write valid code contracts without static checking. I expect that all code developed with VS standard/professional will break many static rules while it runs fine with runtime checking. So in future a huge amount of code will contain invaild rules, forcing developers with VSTS to disable their static checking too.
My recommendation: Disable (don't use) code contracts in VS standard/professional until MS enables static checking for every one (including VS express).
If you use it and publish your code, better cover your tracks..... ;) - Another +1 for shipping it with Professional.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.Now in this case we don't have a free rival on the scenes (that I'm aware of, anyway) but we do have buzz. If MS wants Code Contracts to really change the industry, they've got to put it in the hands of the majority of developers. I'm currently writing about Code Contracts for the second edition of C# in Depth, and it's all very well to talk about the static checker but I really feel I'm almost taunting my readers if most of them won't actually get to use it. I won't claim that the lack of static checking makes Code Contracts pointless, but it does remove a lot of the goodness of it.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.
Jon
Web site: http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet - I have posted a suggestion on Connect. I am afraid that we may be shouting at the wind at this point, but I think this issue is important enough that I am willing to keep shouting. If you feel strongly about this issue, please vote for the suggestion. Maybe, just maybe there is still time to change this if enough people are on board.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=481327
Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com - +1 static checking with pro.
- It pains me to say this, but placing the static checker in team system makes a lot of sense. It's a nice feature but isn't required for most of the benefit of contracts.
It is analogous to code analysis (It forces you to pay attention to small details, and if you run it on an old project you get thousands and thousands of warnings.). and if you run it on an old project you get thousands and thousands of warnings.
That's not true, because an old project will have no contracts defined. Typically, you would be adding contracts step by step on an existing project, and you will get more warnings (that you'll want to fix) along the way.
Visit my blog: http://www.cuttingedge.it/blogs/steven/and if you run it on an old project you get thousands and thousands of warnings.
That's not true, because an old project will have no contracts defined. Typically, you would be adding contracts step by step on an existing project, and you will get more warnings (that you'll want to fix) along the way.
Visit my blog: http://www.cuttingedge.it/blogs/steven/
You're forgetting that the base class libraries have contracts, and the fact that the old project might be coming from VS2010 professional with only runtime contract checking.- Static Checking for all VS developers!
Static checking is a wonderfull tool. But, at this point in time, is still a work in progress.
Code Contracts have a broad user base. And thus, code contracts get a lot of feedback. The feedback for the static checker, however, is a ____ of a lot smaller, because the devs using VSTS are a ____ of a lot less than the whole VS developers in the world.
So, if you want to get more feedback, to build a better static checker (a HUGE selling point for all of VS versions), think about lifting the VSTS restriction. You're forgetting that the base class libraries have contracts
First: if you are using base libraries in a way that breaks their preconditions, you should get warnings and fix them. Hopefully that shouldn't be common, since these warning are likely to indicate bugs.
and the fact that the old project might be coming from VS2010 professional with only runtime contract checking.
Second: are you really arguing "VS2010 Pro shouldn't have static checking, because it's difficult to use on projects created in VS2010 Pro, because VS2010 Pro doesn't have static checking"?It pains me to say this, but placing the static checker in team system makes a lot of sense. It's a nice feature but isn't required for most of the benefit of contracts.
Most of the benefit of contracts IS the static checker. Without it, contracts are just a different way of throwing exceptions. The only thing they add is the ability to specify object invariants, which, while useful, is nothing compared to the advantage that the static checker brings.
It is analogous to code analysis (It forces you to pay attention to small details, and if you run it on an old project you get thousands and thousands of warnings.).
Yes, it IS analogous to code analysis, which should also be in Professional Edition. Yes, running analysis on existing projects which have not previously been analyzed tends to produce a lot of warnings. That's a GOOD thing! It helps shake out the bugs in legacy products.
Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
I tend to agree with everything you've said here.It pains me to say this, but placing the static checker in team system makes a lot of sense. It's a nice feature but isn't required for most of the benefit of contracts.
Most of the benefit of contracts IS the static checker. Without it, contracts are just a different way of throwing exceptions. The only thing they add is the ability to specify object invariants, which, while useful, is nothing compared to the advantage that the static checker brings.
It is analogous to code analysis (It forces you to pay attention to small details, and if you run it on an old project you get thousands and thousands of warnings.).
Yes, it IS analogous to code analysis, which should also be in Professional Edition. Yes, running analysis on existing projects which have not previously been analyzed tends to produce a lot of warnings. That's a GOOD thing! It helps shake out the bugs in legacy products.
Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com- Same thoughts here - without the static analysis I can't see that it would be worth while introducing the code contracts into our production code, it'd be better to stick with the 'old fashioned' way of doing things. I can imagine paying for this functionality but multiplied across the team I could never justify moving to TS - that probably goes for most small/medium sized teams.
If putting it into the Pro edition isn't possible maybe it would be better to think about making Visual Studio modular and charging for individual tools? - It'll be a shame if static checking only becomes available in TS. With the introduction of Code Contracts as a standard component of .NET, we may finally see that Programming by Contract is being widely adopted. .NET as a whole will be so much more powerful. I bet Microsoft will earn more by having this as a competitive advantage for .NET than the few bucks earned on TS licenses ;-)
Code Contracts is pretty useless without the static checker. Without that, it's just a fancy Assertion library.
