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:

dotnet/csharplang#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 iOS<https://aka.ms/o0ukef>

…

________________________________ De : David McCarter <notifications@github.com> Envoyé : Wednesday, August 5, 2020 11:50:04 AM À : dotnet/docs <docs@noreply.github.com> Cc : BKQc <black_knight_qc@hotmail.com>; Comment <comment@noreply.github.com> 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 types<https://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 GitHub<#6361 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABLHMEDCE3GUAP7C45TTZKTR7F5SZANCNFSM4FIZ7ZFA>.

[Joebeazelman]

If you really need safety with little to no penalty in performance, you should consider Ada as a programming language. Its rigid type system alone renders a large subset of contracts and unit tests superfluous. Code is validated statically by the compiler and optionally at runtime via instrumentation. There's also a full-fledged design by contract compiler extension and a variety of unit testing frameworks. If you want ultimate safety, Ada. Its at the level of a super reinforced Volvo for transporting multi-million dollar Faberge eggs across minefields.

It's too bad Microsoft didn't have the vision to acquire Ada's CLR implementation from AdaCore. It would open up huge lucrative markets in aviation, medicine, energy and military who depend on Ada.

[vwheeler63]

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.

@terrajobst @bkqc @RealDotNetDave @SphtKr @TeddyAlbina @mwwhited @jaypatrick @kkm000 @ljr1981

This is really sad. I am a 32-year veteran software developer, heavily steeped in correct use software contracts, trained directly and indirectly by Bertrand Meyer himself. I used contracts (in C) in firmware, in cases where an external chip must only have certain actions done on it when in certain states, and design-by-contract is a HUUUUUUUGGGGGGGEEEEEEE asset in such cases. And in firmware, there are many such cases, as in software. People who think "contracts" are only for null-checking arguments are missing the whole point -- like people who reject Test-Driven Development because they never really experienced its benefits. For those who HAVE experienced its true benefits, NO ONE and NOTHING can un-sell them on use of such excellent tools for reducing software bugs.

Non-nullable references only REDUCES the load on contracts, but never, never, NEVER will it replace it. What non-nullable references does is clears the logs out of the road for REAL software contracts. Apparently the "code bases" examined where written by people who did not understand or properly use software contracts. I can show you a TON of excellent uses of them, and I have lost count of the times that software contracts have "saved my bacon" (i.e. saved weeks or months of finding/fixing hard-to-find bugs), and they have little to do with null arguments.

If you wish to consult, I will invest time and energy and phone time and Zoom meetings to help change this attitude within the .NET developer community within Microsoft. Please give this message to the decision-makers, as they are losing a HUGE asset, and a HUGE reason to use C# and VB.NET for mission-critical projects if this goes away. Maybe Microsoft should hire me to be the flag-bearer for the compiler- and library-level support and use of software contracts....

Kind regards,
Victor Wheeler

[terrajobst]

Non-nullable references only REDUCES the load on contracts, but never, never, NEVER will it replace it.

To be clear, I didn't mean to say that nullable reference types replaced code contracts in its entirety; just that we found that among the users of code contracts the usage of annotations beyond non-null was fairly limited.

My impression is that code contracts are a useful feature but it has never quite taken off, despite significant investment from our side. I'm doubtful that a compelling case could be made for bringing them back.

[vwheeler63]

@terrajobst I understand your statement. Thank you for being frank about it. I'm guessing that in that environment (managers in the Microsoft compiler and .NET library team) that there is a lot of inertia to overcome....

[terrajobst]

The inertia is proportional to the involved cost. Code contracts aren't just a bunch of attributes/methods. They were paired with an IL rewriter and a static code analysis tool. Neither of those are cheap and need to be constantly evolved to support new coding patterns / language constructs.

For the area that I own, I can pretty much decide just between me and my devs. However, when it impacts other teams I need to get their buy-in. And since all teams have desires for features it's usually not in the bucket of "let's just do it". Either they or our joint management has to buy-in to the value proposition and be willing to absorb the cost.

In this case, the challenge is that based on my experience with the feature, my team's experience of using the feature, and based on customer evidence who used this feature, I struggle with believing it being valuable enough to justify the massive cost. Hence, I wouldn't be a good champion for it. At least anecdotally it seems this impression is somewhat shared among the libraries- and compiler teams.

That doesn't mean this feature is forever off the table, but it does mean there would need to be more fairly compelling evidence of its usefulness to justify in building the necessary tools.

[vwheeler63]

@terrajobst Understandable and good description. Thank you for sharing. I'm aware (at least from my perspective) how deep it goes, including inheritance and execution paths that get modified for inherited classes, most especially for the class invariant, but including all the requires() and ensures(). For certain it's not superficial.