Docs: Are Code Contracts going to be supported in .NET Core going forwards?

[JamesKibirige]

There is inconsistent information out there in regards to what is happening to Code Contracts in .NET Core going forwards. Currently, the functionality is not working out the box in .NET Core, I would like to know if Microsoft will be continuing support for Code Contracts in .NET Core?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: d92c6e0f-2503-fe90-2b96-3b0c2054e8dc
• Version Independent ID: 5612b486-e780-7625-12fb-f5478f1be7de
• Content: Code Contracts
• Content Source: docs/framework/debug-trace-profile/code-contracts.md
• Product: dotnet-framework
• GitHub Login: @mairaw
• Microsoft Alias: mairaw

[mairaw]

@terrajobst can you help with this question?

[terrajobst]

We have stopped investing in code contracts a while ago. We've added it to .NET Core 2.0 as part of our compatibility effort, but I wouldn't recommend new code using it.

FWIW, we've looked at many code bases that use them and it seems the overwhelming usage is about null handling. The replacement for this is under way with C# 8's nullable-reference types.

[mairaw]

Thank you for the update @terrajobst. With that, I'm closing this issue.

[kkm000]

@mairaw, I second that. Code Contracts are as dead as the dodo. The sooner this docs page is killed, the fewer people would be confused. A quick look at the issues shows that questions are still asked. We embraced them early, when it was an MSR project at quite early stages (it never graduated, really). There were two parts to it: a static code checking and a runtime code rewriter. The static checker, that proves all the pre- and postconditions and invariants, has a complexity exceeding that of your average theorem prover, and is rooted deeply in a quite complex algebra; it is Byzantine, to say the least, and nobody has ever touched it since @FrancescoLogozzo, the mastermind behind it, left MSR around 2014. This part really needs five years and a research team to keep it churning. The second component, the runtime code rewriter, is a hack that replaces contracts in compiler-generated code with runtime checks after compilation, and relies on certain peculiarities of the old, pre-Roslyn csc compiler's IL layout. As such, it breaks almost completely with Roslyn-produced code.

@SergeyTeplyakov and @mike-barnett did a great volunteer job trying to keep the project afloat at least for a while, and, AFAIK, are both still with Microsoft and probably can update you better than me. And oh boy, do not I wish I were wrong! :-(

[pkulikov]

@kkm000 @mairaw

The sooner this docs page is killed...

What about archiving this page? That is, remove
https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts

and redirect it to
https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/dd264808(v%3dvs.100)

which looks to be the same as the current doc page (except the update done by #7523)

[mike-barnett]

Yes, I agree with @kkm000: the project is unlikely to be revivied. There is no one left to work on it. It would take a tremendous effort to maintain the static checker. Even the runtime checking support would need to be totally re-written.

[jaypatrick]

While I realize from reading these comments that continuing to support this project would be quite expensive, it's unfortunate that this is what's happening. What's even more unfortunate is that nothing is coming along to replace it, b/c DbC is a very powerful coding and architecture paradigm. Is anything going to replace CC? Using it has been invaluable for me in the past.

[terrajobst]

We only have a replacement for non-null.

[bkqc]

Another missing feature since CC is not conitnuing is the documentation benefit it gave (both in SandCastle and with the VS addon in C#). Please bring back something similar that would, using a single line, validate and generate doc (for min, max, returns, ...).

[jaypatrick]

I started going through the code today, it is WAY above my mathematical skills. I can see why nobody wants to take this over within Microsoft now. Oh well, it was fun while it lasted. That being said, something like this wouldn't be too hard to implement with the new Roslyn API's...I hope Microsoft gives this another visit sometime in the future, because the value-add is tremendously beneficial, especially the ability to write all of your contracts to interfaces and have them inherited. It's a great way to centralize guards/etc.

[mwwhited]

Non-null is nothing compared to what code contracts was able to do. It's really a shame that Microsoft abandoned this project like many others.

[clubforge]

@kkm000 @mairaw

The sooner this docs page is killed...

Well, I am still in the process of learning development in the .NET world, and I wish I had read these comments before spending an hour reading about Code Contracts. First I heard of it and thought it was quite interesting. Apparently, I am late to the show and wasted time reading this stuff. I suppose not a total loss, got some bits and pieces as a takeaway.

[TeddyAlbina]

Code contract was a killer feature.

[mwwhited]

Should be even easier with Roslyn... still a shame we didn’t get the compiler pipeline.

[SphtKr]

I'll add to this--I started down the road like @clubforge and others... to have my hopes dashed by the conversation in this issue.

Making matters worse, the subject document had a typo corrected on 9/4/2018 and so the date at the top of the document shows this--_making it look like this information is recent and relevant_, which misled me.

I support the notion that this document should be archived as suggested above, or that some information should be added to it _somewhere_ indicating that "We have stopped investing in code contracts a while ago... I wouldn't recommend new code using it."

Should that be opened as a separate issue, since the original issue title didn't really call for any specific action?

Of note, there _is_ some discussion of supporting a construct like contracts directly in C#, beyond nullable reference types in C#8, here:

https://github.com/dotnet/csharplang/issues/105

We can hope...but that's about it for the moment.

[RealDotNetDave]

We have stopped investing in code contracts a while ago. We've added it to .NET Core 2.0 as part of our compatibility effort, but I wouldn't recommend new code using it.

FWIW, we've looked at many code bases that use them and it seems the overwhelming usage is about null handling. The replacement for this is under way with C# 8's nullable-reference types.

Did it ever work in Core? There isn't a rewriter as far as I know.

I disagree with killing Code Contracts. If you want to create something new for Core then fine, BUT WE NEED SOMETHING!

David

[bkqc]

Code Contracts is way more than null checking!
It does static analysis of boundaries, static state and multiple other things in a way that is clear and usable in generated documentation!

Téléchargez Outlook pour iOShttps://aka.ms/o0ukef

---

De : David McCarter [e-mail]
Envoyé : Wednesday, August 5, 2020 11:50:04 AM
À : dotnet/docs [e-mail]
Cc : BKQc [e-mail]; Comment [e-mail]
Objet : Re: [dotnet/docs] Are Code Contracts going to be supported in .NET Core going forwards? (#6361)

We have stopped investing in code contracts a while ago. We've added it to .NET Core 2.0 as part of our compatibility effort, but I wouldn't recommend new code using it.

FWIW, we've looked at many code bases that use them and it seems the overwhelming usage is about null handling. The replacement for this is under way with C# 8's nullable-reference typeshttps://blogs.msdn.microsoft.com/dotnet/2017/11/15/nullable-reference-types-in-csharp/.

Did it ever work in Core? There isn't a rewriter as far as I know.

I disagree with killing Code Contracts. If you want to create something new for Core then fine, BUT WE NEED SOMETHING!

David

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/docs/issues/6361#issuecomment-669271897, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABLHMEDCE3GUAP7C45TTZKTR7F5SZANCNFSM4FIZ7ZFA.