This repository was archived by the owner on Jul 15, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Jul 15, 2023. It is now read-only.
How to enable "perform runtime contract checking" in Visual Studio 2017? #492
Description
Hi All,
I have VS 2017 community edition. I need to enable "perform runtime contract checking" on Code Contracts pane. But I don't see that pane anywhere in the project properties.
Any idea on how to enable this in Visual Studio 2017 community edition.
Thanks in advance.
Regards,
Sai
Reacted by Nathan Phillip Brink and Mikhail
Activity
rjgotten commentedon Aug 16, 2017
VS 2017 is not supported yet and if the current trend continues might not be supported ever. :(
SaiSK88 commentedon Aug 16, 2017
rjgotten
Which version of VS has a good support for this?
rjgotten commentedon Aug 16, 2017
VS 2013 is the last version that was fully supported by Microsoft itself, before the project was handed off to the community.
The VS extension itself works well with VS 2015 if you use the latest release candidate from the community. However, the IL-code rewriter still has some issues with the new C# 6 features and the Roslyn compiler. Some are resolved in the community release candidate and some still aren't.
And then there's C# 7 and .NET 4.7. Which is - from my understanding - thoroughly incompatible with the current IL-code rewriter. That's probably also the reason the extension itself isn't available for installation in VS 2017 yet.
johncrim commentedon Oct 5, 2017
See these 2 posts (my answers) for info on how to enable code contracts runtime checks in VS 2017 builds:
https://stackoverflow.com/questions/40767941/does-vs2017-work-with-codecontracts/45746311#45746311
https://stackoverflow.com/questions/44299848/net-standard-net-core-code-analysis-and-code-contracts-with-vs-2017/46551755#46551755
tom-englert commentedon Oct 6, 2017
John Crim (@johncrim) but be aware that you can't rely on CC runtime checks in VS 2017.
Du to the C# 7 IL-code it does not detect or report many issues - so it's rather useless if you can't rely on it 100%.
johncrim commentedon Oct 6, 2017
Thanks for the comment tom-englert (@tom-englert) - do you know what was added or changed in IL for C# 7?
Looking at https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/, the only new feature that jumps out at me RE possible changes to IL are local functions - I'll have to test that.
yaakov-h commentedon Oct 7, 2017
I know of only one horribly breaking change - if you have two or more
awaits inside atry/using/foreachblock, the emitted state machine is slightly different andccrewritechokes on that - I think only when usingContract.Ensures.tom-englert commentedon Oct 7, 2017
John Crim (@johncrim) it's not the language features, it's the different lowering patterns that the new compilers are using, which CC's IL parser does not recognize. I can't make it up to something special, just realized once when I compiled a project with VS2015 that had no CC warnings in 2017, but reported lots of missing checks in 2015.
johncrim commentedon Oct 8, 2017
Yaakov (@yaakov-h) - I'd seen problems with
awaits, including #483 . I've found that a new build (but not the latest release build) works for the problems I'd encountered. There may be other open async bugs in the latest code that we haven't encountered.It may not be time well spent given Microsoft's (lack of) commitment to code contracts, but it would be great to add test cases for VS 2017 issues that people come across.
tom-englert commentedon Oct 9, 2017
John Crim (@johncrim) unfortunately the test framework is only testing with the .Net3.5 and .Net4.0 compiler.
The tests include so much checks on compiler details that making the tests run with a newer compiler is IMO nearly impossible.
Porges commentedon Nov 22, 2017
It feels like, with Roslyn, the "rewriter" should instead be working at the syntax tree/compiler level so that it isn't broken by small IL changes.
mike-barnett commentedon Nov 22, 2017
Yes, that is definitely true. But Roslyn has a read-only view of the tree, so you'd have to do the rewriting and then write out the resulting compilation to a different file and then swap them in a post-build step.
yaakov-h commentedon Nov 22, 2017
dotnet/csharplang#107
kkm000 commentedon Nov 29, 2017
Mike Barnett (@mike-barnett), tom-englert (@tom-englert) Yaakov (@yaakov-h): I think that https://github.com/AArnott/CodeGeneration.Roslyn has enough functionality to replace ccrewrtie and ccdocgen. But to me the cherished part is the static analysis. What do you think of both the above codegen, and how to go on with the static analyzer? The guy sitting literally next to me wrote his PhD on the static analysis of code flow (his implementation in LISP and for C); I combed through his thesis, and I do appreciate the complexity of the deal. To me, it looks like writing one is a full-time work... for more than one person, 'fraid. What do you guys think? Let's speak our hearts out!
yaakov-h commentedon Nov 30, 2017
That's why it took an entire team of PhD researchers to build this, and it'll likely take the same to update and maintain this.
Contracts is effectively abandonware.
Any modern analysis should probably sit on top of Roslyn and it's flow analysis, at which point you're basically starting over anyway.
kkm000 commentedon Nov 30, 2017
Yup. And a big question is whether the flow API is going to be around for a while, for some uncertain definition for "a while". There is a blog post by Josh Varty of Microsoft, of whom I never happened to hear before, and, though the post is a couple years old, this statement does not sound super encouraging:
With this much use it might disappear before someone is half way through implementing a workable the static flow analyzer. Any word out there on the chances of this API rolling forward with the rest of Roslyn?
yaakov-h commentedon Nov 30, 2017
Well that is from nearly 3 years ago, and I believe the underlying systems are used by Nullable Reference Types.
mike-barnett commentedon Nov 30, 2017
I hadn't known about Andrew's work before; that looks super promising. A big part is to also persist the contracts somewhere so they can be retrieved while processing assemblies that have references to them. This is needed for contract inheritance. I think it would be very difficult to continue with the current static checker. That would take a lot of work. However, I'm very encouraged by the directions that the Roslyn team is taking. I think there will be a good dataflow analysis framework in the future and something could be built on top of that.
kkm000 commentedon Nov 30, 2017
Yaakov (@yaakov-h) Looks like a pretty solid bet then, thank you!
Mike Barnett (@mike-barnett): Yes, looks very promising! I'm going to get my hands wet in it. With unrewritten contracts throwing in BCL 4.7, the rewrite part is more in the way. And easier to tackle than static analysis, too.