none
Is Code Contracts dead?

    Question

  • Sorry about the sensationalist title, but my intent is to be a bit blunt and try to elicit some response from the dev team on this. Wake up guys!

    The situation: After waiting for several months for proper Visual Studio 2012 support, we only have complete radio silence from the team regarding this. In these circumstances, people tend to think they are not replying intentionally, for some unknown reason, or so busy applying resources in some other area that they don't even take a look at these forums.

    Is this the case? Can anyone from the team at least confirm Visual Studio 2012 support WILL be offered at some point? Or are you dropping support for Code Contracts altogether?

    Just in case, I know the latest version is supposed to offer this, but if you take a look at related posts here, you'll see it is not working for most of us). Also, Visual Studio 2012 Editor Extensions were said to be delivered during November, but they are not to be found anywhere.

    I hope Code Contracts will live a long life and eventually become part of the framework and compiler, but the current situation is kind of discouraging on that regards. You've done great work so far, listen to the community and push the project forward a bit! In the end, if things are looking grim from up-high, release the source code so the community can take over.

    Friday, February 15, 2013 4:56 PM

Answers

  • Hello,

     We understand the concerns about our level of support for Code Contracts. We are an extremely small group within Microsoft Research. We do not have the resources of a product group, but we believe very passionately in the technology and are trying our best to support the community that has found our tools to be useful.

    Here are some news on our project (which is still alive ;-)

    Current release:

    1. Code Contracts has moved from DevLabs to the VS Gallery. (As Soma announced, all of the DevLabs projects have moved to the gallery.) We will be discontinuing the release from the Microsoft Download Center.
    2. Along with the move we have released a new version, 1.4.60218.0, that fixes the longstanding problem with the debugging of async and iterator methods in rewritten assemblies.

    Future of all tools except for the static checker (i.e., the binary rewriter for runtime checking, the reference assemblies, the documentation generation, and the editor extensions):

    1. All of these tools will be released as an open-source project using the Apache license. We will continue to maintain them, but this will give a chance for others to investigate (and perhaps fix) problems that are of particular concern.
    2. We will publish documentation on how to create reference assemblies for third-party assemblies.

    Future of the static checker:

    1. We will continue to do research on static checking and will actively develop new features.
    2. We are particularly interested in static analysis in the cloud and the smart programming assistant.
    Tuesday, February 19, 2013 10:26 PM
    Owner

All replies

  • I have Visual Studio 2012 Ultimate and I installed the code contracts msi. I tried running static analysis and it didn't work out so well. The tools seem to have integrated but apparently I have more fixin to do. But the tools installed properly...

    Juan, what are you saying isn't working?

    Friday, February 15, 2013 7:48 PM
  • If it's not dead, it is certainly dying. Unless there is an official announcement from the BCL team regarding compiler / language integration, which would probably be VS2014 at the earliest, it should be put out of it's misery. 

    1. Project started ~ 2008 (probably before) and we've had 2 major iterations of VS. If it's not out of devlabs by now, it'll never be.
    2. There appeared to be no resources assigned to ensuring VS2012 compatibility with a sync release (hint: nobody cared).
    3. The Contracts dev team have gone radio silent (hint: they're not working on it any more).
    4. The community are abandoning it
    5. It's companion project, PEX, is discontinued (with a part making it into MSTest).
    6. There appears to be a de-emphasis on static managed languages in MS with a resurgence of C++/COM and increased emphasis on JS (or TypeScript). The developer resources are doing other things.
    7. The static analyser was always buggy it may be either the problem is just too difficult to properly solve, or it is actually unsolvable in .net.

    I'm in the process of scrubbing my code base and am nearly there. Lesson learned: do not rely on a DevLabs project.

    • Proposed as answer by Fahime71 Tuesday, October 07, 2014 5:19 AM
    • Unproposed as answer by Fahime71 Tuesday, October 07, 2014 5:19 AM
    Sunday, February 17, 2013 1:35 PM
  • Hi,

    > Unless there is an official announcement from the BCL team regarding compiler / language integration

    I doubt CC will ever be integrated into the compiler.  That's not a good metric as to whether Code Contracts is "dead".

    As Eric Lipper puts it:  

    Now, you might note that tools like the Code Contracts feature [snip] all have various abilities to statically detect possible or guaranteed null dereferences. Which proves that it is possible to do a good job of this feature, and that's good to know. But that is also points against doing the warning in the compiler. [snip] [I]f an existing analysis tool does a good job, then why replicate that work in the compiler? The compiler does not aim to be the be-all and end-all of code analysis; in fact, we are building Roslyn precisely to make it easier for third parties to develop such analysis tools. We can't possibly do every great code analysis feature, but we can make it easier for you to do so!

    I have a feeling that the CC team is investing heavily in Roslyn, which may be why we haven't seen much from them in terms of CC updates and VS 2012 integration.

    > Project started ~ 2008 (probably before) and we've had 2 major iterations of VS. If it's not out of devlabs by now, it'll never be.

    Maybe Roslyn is the target.  Regardless, if the tool is useful, then what's so bad about the "devlabs" label?  I'd like to have something "official" as well, but let's face it, being official doesn't guarantee anything but a support channel.  It makes no real guarantees about the lifetime of a product, at least in terms of updates and VS integration.

    > There appeared to be no resources assigned to ensuring VS2012 compatibility with a sync release (hint: nobody cared).

    Again, let's at least wait until Roslyn is released, or an update of CC is released before VS vNext, or the CC team actually states that CC is "dead"; whichever comes first.

    > The Contracts dev team have gone radio silent (hint: they're not working on it any more).

    This is just plain wrong. Manuel just responded to this post 4 days ago. Please get your facts straight before starting rumors :)

    Also noteworthy is Manuel's comments, implying intention to possibly fix the reported issue in a future release:

    The only work around at the moment is to disable the rewriter for the debugging session.

    > The community are abandoning it

    Really?  What makes you think that?  Once a tool or library becomes fairly stable, it's only natural for the number of active threads in its usability forum to decrease.  But this forum is still certainly in use for people asking questions and getting answers.  Though perhaps most of the posts are simply unanswered bug reports, but that doesn't mean that nobody is reading them or fixing the bugs.

    > It's companion project, PEX, is discontinued (with a part making it into MSTest).

    That's a completely different project.  I don't see how it's a "companion" at all, except maybe that they were being developed at around the same time and maybe even some of the same people were involved at one point, though I don't even know if that's true.

    > There appears to be a de-emphasis on static managed languages in MS with a resurgence of C++/COM [snip] JS (or TypeScript).

    Roslyn.

    > The static analyser was always buggy it may be either the problem is just too difficult to properly solve [snip]

    For me and I assume many others, Code Contracts has been and will continue to be an extremely useful tool.  Admittedly, the lack of support for async/await and iterator blocks makes it somewhat limiting though.  But there will always be bugs and limitations.  It can never be perfect.

    > I'm in the process of scrubbing my code base and am nearly there. Lesson learned: do not rely on a DevLabs project.

    That seems really premature and also a bit pointless if you were actually getting value from using Code Contracts.

    Perhaps the only proper metric to determine whether Code Contracts is "dead" or not is whether or not we get a new release in the future.  We aren't entitled to one, nor are we entitled to be told when we will get one, so we can't really know whether it's dead unless they explicitly tell us that we won't be receiving any more updates, and I haven't seen such a message from the CC team yet.

    My hope is that they are simply investing heavily in Roslyn and it's taking up most of their time in Code Contracts, assuming that they have responsibilities on other projects as well.

    - Dave


    http://davesexton.com/blog

    • Edited by Dave Sexton Sunday, February 17, 2013 3:41 PM Spelling
    Sunday, February 17, 2013 3:32 PM
  • Microsoft is usually rather bad at being open when things aren't going so well. The latest example is the (extremely) limited quantities of the Surface Pro Tablet-notebook.
    Code Contracts is likely in a development cycle, and we'll hear more in a year or so... and it will be completely unready for C# 6.0

    Sunday, February 17, 2013 11:37 PM
  • Sadly today I've filed a product backlog item about CC removal from all of our project. Reasons are above, but there are two unnoted issues aswell:

    - Turning on CC rewrited makes build times INCREDIBLY LONG. We're tired of waiting for a fast rewriter, it's enough.

    - CC rewrited makes impossible to debug async methods since locals are not visible.

    It's sad, and what makes it sadder is that Contracs class is a part of core System.Diagnostics namespace and it should be supported by the Framework and compilers itself since years.


    Monday, February 18, 2013 9:20 AM
  • Hello,

    Just sharing my opinion about this, I'm doing TDD and I really can't be bother for the rewriter to finish, as you pointed out it really takes time so what I did was creating a new build configuration and disabled CC completely.

    You can do the same thing, create a special debug build and disable it, however, it might not be feasible if you're using the generic version of Contract.Requires.


    Regards,

    Eyal Shilony

    • Edited by Eyal Solnik Tuesday, February 19, 2013 1:56 AM
    Tuesday, February 19, 2013 1:30 AM
  • Are any of your assertions fact (inside knowledge) or hypothesis?

    For a start, CC will have to be integrated into the compiler - ILRewriting on each compile is just not viable long term.

    Your example of team community engagement is Manuel responding to responding to a 4 month old thread with an apology...

    The traffic in the forum has gone appears to have gone down which is a strong indication of community abandonment.

    >  Though perhaps most of the posts are simply unanswered bug reports, but that doesn't mean that nobody is reading them or fixing the bugs.
    I clearly interpret that differently to you.

    Code Contracts and Pex: Power Charge Your Assertions and Unit Tests Mike Barnett, Nikolai Tillmann  http://www.microsoftpdc.com/2009/VTL01

    You keep saying Roslyn is (will be) the answer. Again, is this inside knowledge or you hypothesising? (Also Eric Lippert is no longer with msft.. hmm...)

    4/5 years is not premature. I, and many others in this forum, appear to have gotten some value, but now it is certainly costing me more.

    can't really know whether it's dead unless they explicitly tell us

    I did say "dying"...


    • Edited by DamianHMVP Tuesday, February 19, 2013 3:38 PM
    Tuesday, February 19, 2013 3:38 PM
  • Hello,

     We understand the concerns about our level of support for Code Contracts. We are an extremely small group within Microsoft Research. We do not have the resources of a product group, but we believe very passionately in the technology and are trying our best to support the community that has found our tools to be useful.

    Here are some news on our project (which is still alive ;-)

    Current release:

    1. Code Contracts has moved from DevLabs to the VS Gallery. (As Soma announced, all of the DevLabs projects have moved to the gallery.) We will be discontinuing the release from the Microsoft Download Center.
    2. Along with the move we have released a new version, 1.4.60218.0, that fixes the longstanding problem with the debugging of async and iterator methods in rewritten assemblies.

    Future of all tools except for the static checker (i.e., the binary rewriter for runtime checking, the reference assemblies, the documentation generation, and the editor extensions):

    1. All of these tools will be released as an open-source project using the Apache license. We will continue to maintain them, but this will give a chance for others to investigate (and perhaps fix) problems that are of particular concern.
    2. We will publish documentation on how to create reference assemblies for third-party assemblies.

    Future of the static checker:

    1. We will continue to do research on static checking and will actively develop new features.
    2. We are particularly interested in static analysis in the cloud and the smart programming assistant.
    Tuesday, February 19, 2013 10:26 PM
    Owner
  • I really hope that the announcement of the static analysis in the cloud will not turn into the only choice. :p

    Thank you for the hard work.


    Regards,

    Eyal Shilony

    Tuesday, February 19, 2013 10:53 PM
  • Thank you Francesco!

    - Dave


    http://davesexton.com/blog

    Wednesday, February 20, 2013 1:27 PM
  • Thank you for the update Francesco.

    Microsoft appears to do two kinds of 'open-source' projects. The first kind that can't accept pull requests and thus can't be improved / helped by the community (xunit, nlog, katana until recently). This is basically "shared-source" with rights to fork. The second kind is a proper OSS project that has active community involvement, including accepting code (nuget, aspnetwebstack). It looks like you are considering the latter, and if so, I look forward to hopefully revising my assertions :)

    Thursday, February 21, 2013 6:58 PM
  • @DamianH, to my understanding xUnit is not a Microsoft project and never was, the people who are working on the project happened to work there and to current date Brad is no longer working there. :D


    Regards,

    Eyal Shilony

    • Edited by Eyal Solnik Wednesday, February 27, 2013 12:49 PM
    Thursday, February 21, 2013 8:55 PM
  • Thank you, Francesco. Hope to see your work going forward. Anders keeps hammering on the benefits of static typing, so this should be well aligned with Microsoft's push in that direction.
    Monday, March 04, 2013 4:57 PM
  • @Eyal I know

    https://twitter.com/ploeh/statuses/225523026949705728

    The project still hasn't been moved to the outercurve foundation.

    It took Brad six months to fix a critical issue I reported ( http://xunit.codeplex.com/discussions/262833http://xunit.codeplex.com/workitem/9732 ). I even included the solution with the report and would have sent a PR that day.

    It remains to be seen whether code contracts is will be a properly run OSS project or dump-ware.




    • Edited by DamianHMVP Wednesday, March 06, 2013 4:09 PM
    Wednesday, March 06, 2013 4:08 PM
  • @Damian, ahh okay. :)

    oh my gosh these legal stuff...


    Regards,

    Eyal Shilony


    • Edited by Eyal Solnik Wednesday, March 06, 2013 5:47 PM
    Wednesday, March 06, 2013 5:45 PM
  • As an active user of Code Contracts, my two main points are:

    1. Please do not abandon it. It is a great tool.

    2. For it to be usable in long term, it must be improved in *many* ways.

    Ad 1: Code Contracts has helped me to significantly impove the quality of the code base. It is regularly finding issues that would be otherwise costly to spot. I understand that the team wants to continue improving the static analysis, andf that's good, but at least for our usage, it is actually quite satisfactory as it is now. The interest in "static analysis in the cloud" etc. might be an indication that eventually the static checker may become a paid service and Microsoft will monetize on it. In general I have no problem with it. BUT I have a very powerful machine, and could do much more of static analysis, though I have to sadly observe the static analyzer to use only one of 12 virtual processors. So, to make it faster, the logical first move would not be to use the could, but implement parallelism in the analysis.

    Ad 2. Microsoft need to fully understand one thing: The people who use Code Contracts are those who are highly interested in the code quality. As such, they are not going to use Code Contracts alone. They need to use it together with other tools. And that's where Code Contracts fails in every possible way. And that's what may even kill it, unless it is addressed will full Microsoft weight - and I do not think the open-sourcing of the rewriter indicates a move in the right direction. Here are some examples:

    - The rewriter is in conflict with Code Analysis (for years already!)

    - CC does not work well with ReSharper out of the box.

    - CC does not work with Fakes (imagine this! - you cannot even use MS test tools with it)

    - Documentation generation crashes on many projects.

    - Documentation generation does not work well with Sandcastle/SHFB.

    There appears to be thinking that the rewriter is not that important, bcause the "cleverness" or added value of CC in in the static analyzer. That may very well be true for "closed" executable applications - after all, if you analyze and prove all your assertions, runtime checking becomes unnecessary. BUT we - as many others - are developing APIs (libraries) for other developers to use, and then the runtime checks (on the external surface) are absolutely essential to the usability of the API, and that's why I feel the rewriter should also remain in the main focus area of Microsoft developers internally.

    Monday, May 27, 2013 12:06 PM
  • @FrancescoLogozzo - It doesn't look like the Code Contracts project ever made it to open source.  Is this still the plan?  If so, what's the timeline?  If not, do you still maintain that the project isn't dead?

    smartcaveman

    Friday, June 06, 2014 6:27 AM
  • No, CodeContracts is not dead.

    In the last year we focused more on first party, so that's why you heard less from us...

    We did most of the steps to release (some of) the tools as open source, we have just to go the last mile. Your post probably will push us ;-)

    We worked on new features for the static checker (e.g., check my web page) to reduce the number of alarms.

    Also with my intern we created a tool, ReviewBot, which uses Roslyn to automatically (in batch mode) instrument a C# code base with the contracts suggested by the tool.

    I am polishing the code and started the process to open source ReviewBot too.

    Finally, I have a question: we'd love to stress test ReviewBot on some code, can you suggest us some projects (using git) to try it onto?

    thanks

    francesco

    Friday, June 06, 2014 7:01 PM
    Owner
  • Finally, I have a question: we'd love to stress test ReviewBot on some code, can you suggest us some projects (using git) to try it onto?

    I guess you can use Umbraco, NBehave or AutoFixture just random projects that came to mind.

    Regards, Eyal Shilony

    Wednesday, June 11, 2014 7:21 PM
  • Hi Francesco,

    I am more than happy to trial ReviewBot if possible. We still firmly believe in the Code Contracts project and are in the process of retrofitting to an existing code base. ReviewBot would be perfect for this project (it currently has 1040 dll's (495 megabytes) so would certainly be a great stress test). I don't think there is a bigger C# project anywhere, but I could be wrong.

    Regards,

    Brett


    Thursday, June 12, 2014 4:21 AM
  • When we start a new solution, the first thing we do is to add a new solution configuration. 

    • Debug
    • Debug CC
    • Release

    We only enable Code Contracts for Debug CC.

    Then we code along happily in Debug mode and switch to Debug CC when a feature set is getting into shape, as part of definition of done. 


    Wednesday, June 18, 2014 7:36 AM
  • Hi - Any chance of getting our hands on ReviewBot?
    Monday, October 06, 2014 11:24 PM
  • Send me your GitHub login and I will give you access.

    ciao

    f

    Monday, October 06, 2014 11:26 PM
    Owner
  • BrettShearer
    Tuesday, October 07, 2014 12:15 AM
  • alfredmyers

    Alfred Myers http://alfredmyers.com | http://twitter.com/AlfredMyers

    Tuesday, February 02, 2016 7:48 PM
  • Yeah, so... in line with the OP and more than 3 years later, I'm giving up of Code Contracts. No activity either here or on GitHub, and between the performance hit and issues with NCrunch and with async code, I've now completely switched to https://github.com/Fody/NullGuard

    It only covers null checks but those are the vast majority anyway, the performance impact is negligible and it supports ReSharper's NotNull/CanBeNull annotations so many issues (but not all) can be detected via the real-time static analysis.

    It's not perfect, but it works, it's fast and it's supported. Three things that can't be said about Code Contracts, unfortunately.

    So until there's a magical revival of the support, and/or (ideally) it ends up being integrated into the language, goodbye Code Contracts. I just can't justify relying on this anymore, which is a shame. Loved the idea (still do), loved the static analysis, but the support just isn't there...

    Monday, March 14, 2016 4:51 PM
  • I don't think so.
    Monday, March 14, 2016 5:06 PM
  • Add another user who has given up on Code Contracts. It just doesn't work. Every time VS gets released, I'm down until they update it. Then the last straw was MS pushing out Windows Anniversary Update to my PC last night, after which, none of my contracted projects build any more due to some inability to load an internal CC assembly.

    To make matters worse, I can't just disable the damn thing. I remove the Perform * Checking boxes, I set the reference assembly to None, but every time my code hits a contract, it complains that CONTRACTS_FULL is defined (it's not). The only option I have now is to go through EVERY contract and replace them with an if-then-throw (which is the reverse of what I spent a week doing several years ago when CC was first released).

    It's just a colossal pain in the ass, and it has always been. I just wish MS had made it easier to turn it off rather than forcing me to go through hundreds of .cs files and manually clean it all up. Thanks for the extra work I have to do, MS!

    EDIT: And, oh, yeah, NO SUPPORT!  All I can do is go to these forums and plead for someone to tell me how to unscrew my solution, but so few people even use CC that it's a futile endeavor. MS has dumped the onus on that to the community, but they don't seem to get that some of these projects are too niche for the community to be able to handle the support. YOU WROTE IT, YOU SUPPORT IT.  Or kill it...make it dead and stop pushing a headache on us.



    • Edited by RKPatrick Saturday, October 01, 2016 11:29 AM
    Saturday, October 01, 2016 11:00 AM
  • Is this still the case? As of 24 hours ago (Win10 Anniversary Update), Code Contracts stops building on my machine. I can get no support for the problem (did Anniversary remove a required .Net version? did it screw up on C++ runtime? What happened!??!?!) I can't even just turn the thing off, as any time the runtime hits a contract, it throws up an error saying I need to enable contracts (I just want to turn it off until MS gets its act together).

    And furthermore, because contracts are so pervasive in my app, I'm up at 5am on a Saturday going through and commenting out every...single...one (and many are multi-line, so I can't just search/replace).  I've given up on the thing and am finally ripping it back out, but it really REALLY ticks me off that MS pushes something like this (STRONGLY coupling it to my code) and than constantly screws with it to the point where I am forced to pull about 1000 lines of code out one-by-one!

    The easiest way to fix this is to have some flag that the code recognizes to no-op all the contracts (but I read some MS'er post I think on StackOverflow saying that this isn't something I'd want to do!). Right now, the damn thing says I have CONTRACTS_FULL defined, but I supposedly can't undefined it globally. I can't disable it from project settings because even with zero checkboxes checked, it still complains about the contract rewriter. I HATE THIS THING! A LOT.

    Saturday, October 01, 2016 11:29 AM
  • I too am looking into Fody.

    The latest GitHub release: https://github.com/Microsoft/CodeContracts/releases seems to be full of fixes... but your comment about the lag on my build time scares me investing in CodeContracts.


    Appreneur Application Architect Software Ronin

    Friday, December 09, 2016 6:34 AM