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.