How to enable "perform runtime contract checking" in Visual Studio 2017? about codecontracts

[Porges]

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.

[rjgotten]

VS 2017 is not supported yet and if the current trend continues might not be supported ever. :(

[rjgotten]

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.

[yaakov-h]

dotnet/csharplang#107

[yaakov-h]

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.

[SaiSK88]

@rjgotten

Which version of VS has a good support for this?

[johncrim]

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]

@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]

Thanks for the comment @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]

I know of only one horribly breaking change - if you have two or more awaits inside a try/using/foreach block, the emitted state machine is slightly different and ccrewrite chokes on that - I think only when using Contract.Ensures.

[tom-englert]

@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]

@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]

@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.

[mike-barnett]

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.

[kkm000]

@mike-barnett, @tom-englert @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!

[kkm000]

at which point you're basically starting over anyway.

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:

I put out a tweet asking how others were using [the data flow API], and it appears they’re only really used within Microsoft to implement the “Extract Method” functionality.

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]

Well that is from nearly 3 years ago, and I believe the underlying systems are used by Nullable Reference Types.

[mike-barnett]

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]

@yaakov-h Looks like a pretty solid bet then, thank you!

@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.