none
Code Contracts getting out of "Research Projects"

    Question

  • Hi,

    Is there any plan to include Code Contracts (including the tools) in the next version of Visual Studio? I personally have been using it for a couple of years, but I can't force other team members to do the same because it is still a "research project". If Code Contracts stays the same status, serious programmers wouldn't want to use it.

    Regards,

    Tetsu


    tetsu
    Thursday, January 05, 2012 1:56 PM

Answers

  • Sigh. Yes, we know this is a problem. We have a long-term engagement with the Visual Studio folks and have ongoing discussions with them about the future of Code Contracts. Unfortunately it is not going to change in the Dev11 timeframe. We will, of course, post any news if things change...
    Mike Barnett
    Thursday, January 05, 2012 3:48 PM
    Owner

All replies

  • Sigh. Yes, we know this is a problem. We have a long-term engagement with the Visual Studio folks and have ongoing discussions with them about the future of Code Contracts. Unfortunately it is not going to change in the Dev11 timeframe. We will, of course, post any news if things change...
    Mike Barnett
    Thursday, January 05, 2012 3:48 PM
    Owner
  • Sigh.

    Ah Mike, I feel your frustration. You guys have been working on this for many years now. I remember your PDC'09 session with Nikolai and left very impressed.

    My team and I have bought into it, and we use it extensively. I sorely disappointed to not hear about any real integration (at compiler) level for dev11/.net 4.5.

    I hope that if you have any inclination that it won't make it past DevLabs, that you will let us know sooner rather than later.

    It's a great tool, I hope it progresses to full product.

    Thursday, January 05, 2012 8:21 PM
  • Hi Mike,

    The fact that such an infinitely important feature continues to be ignored by the relevant teams (VS, compiler, WinFX?) at MS while the most lame-brained efforts (horrid new VS 11 UI) get attention and priority is mind-boggling. I can't believe that CodeContracts is going to miss the .NET 4.5 / VS 11 wave - it should have been in .NET 4.0 / VS 2010. I can't describe how disappointing this is.

    It's things like this that make a long-time customer like us question whether Microsoft is too out of touch with the needs of developers. I know that this sorry state is despite your team's best efforts and I'm sure you guys are just as frustrated as we are, but the higher-up decision makers are going to doom your work on CodeContracts to be limited to the minority of users that like playing with pre-release software.

    It's just such a shame...


    • Edited by AbinsDev Wednesday, March 21, 2012 12:54 AM Minor grammar correction
    Tuesday, March 20, 2012 6:35 PM
  • Yes, you'd think especially with all the talk about pushing to open up the compilers (a la Roslyn) that Microsoft would take a step back, hold off a few months on shipping, and really make something with an enormous value-add.

    Who knows?  They made the decision to hold off back in VS2010 after the performance issues, so maybe they'll listen to their customers this time?  I really hope so - the whole "developers, developers, developers" aura that I hear "old-timers" talking about needs to be recaptured, and not just for Windows 8's sake.

    And I agree with AbinsDev - Code Contracts is actually mission-critical for the work I'm doing.  In fact, it's the main reason that I decided to stay on the Windows platform with my product - because none of the mainstream alternatives have the same level of support for formal methods.


    Lars Kemmann

    Tuesday, March 20, 2012 6:45 PM
  • Hi Mike,

    I asked a similar question to this one yesterday in these same forums, except that mine had more of an emphasis on the CodeContracts components simply reaching release status (rather than full Visual Studio integration) than this one.

    http://social.msdn.microsoft.com/Forums/en-US/codecontracts/thread/891230dc-7352-4ab7-be42-bc13bef1579d

    Any answer you can give on that question would also be appreciated, and I think be of interest to those reading this thread, too.

    Thanks.

    Wednesday, March 21, 2012 10:21 PM
  • The part this truly confusing is that "System.Diagnostics.Contracts" ships with the framework but is effectively useless without downloading "research" binaries. It's like Microsoft shipped half of the product.

    In my opinion this should not have been shipped at all until it was DONE. I truly hope that I don't have to double check every object in the .Net Framework to see it's really there and fully functional or not. Seriously, what developer would want to work in a Framework where parts are not even functional?


    • Edited by DavidLarson Tuesday, August 28, 2012 6:17 PM
    Tuesday, August 28, 2012 6:04 PM
  • Hi,

    I suspect there were two reasons for including the contract APIs in the .NET Framework while the tools were still under development:

      • The contract APIs are merely a mechanism for specifying contracts.  The APIs were stable (enough) and could be used independently from the CC tools that were still under development.  By including APIs in the FCL, it enabled third-party developers to take advantage of a unified model for DbC within the .NET Framework.  It's all about the metadata.  This could enable supplementary analysis tools to be developed independently; e.g., better VS integration, Resharper analysis, .NET Reflector support, etc.  Though as it turns out, there isn't any supplementary support out there yet from third-parties, I believe.
      • To indicate a commitment, on some weak level perhaps, to the concept of DbC and to the CC tools that were still under development.  I'd guess that the purpose of this was to get people to start using CC sooner rather than later.

    - Dave


    http://davesexton.com/blog

    Tuesday, August 28, 2012 7:16 PM