CodeContracts fail with CONTRATS_FULL reference in ASP.net vNext

[glatzert]

I made a little project (ASP.net vNext DLL Template) with a test project. The test project uses xunit and xunit.runners.dnx. Running the test will fail on Contact.Requires(a != null) with a hint to CONTRACTS_FULL being set somewhere.

How can Code contracts be used in new ASP.NET Projects?
Can they be used at all? Or are contracts now "deprecated"?

[BalassaMarton]

Same result when using CodeContracts in an ASP.NET 5 web application. I've installed the CodeContracts NuGet package for the project, but there is no Code Contracts tab in the project properties window. Is there any magic strings I should put in project.json or the .xproj file to make this work? The problem is, I moved a lot of files from a class library (that was using CodeContracts) to the ASP.NET project, so finding and deleting all Contract.Requires lines would be tremendous work, not to mention that I do want to use CC.

[roji]

+1

@SergeyTeplyakov, can you please let us know if there are plans to add support to CC runtime checkingfor project.json-based builds? This could probably be done with a post-build DNX command.

With all the effort going into DNX and project.json it's important to know whether CC will be compatible...

[SergeyTeplyakov]

@roji It sound like a very good feature in general. If someone has experience with this stuff and can implemnet, I would be happy.

My only concern, that DNX and project.json should work on CoreCLR and I have no idea how CC will play there.

[roji]

@SergeyTeplyakov, I think there are several things here:

• Provide a post-build DNX command that calls ccrewrite. This isn't related to .NET Core - you can target regular net45 with DNX/project.json and it should be possible to use CC in this scenario. This is probably a pretty easy task - you need a place to store all the CC settings (probably a CodeContracts.json alongside the project.json).
• Make CC work on .NET Core assemblies in general, both rewriting and static analysis. I don't think there are any IL differences between .NET Core and .NET Framework, or relevant API changes, so I'm not actually sure there's something to be done here.

We should probably have two different issues for these.

[psmolinsky]

+1

[TsengSR]

Any update on this? I'd really need code contracts in dnx packages/asp.net 5 web projects

[pedrotainha]

I'd love to know more about this also. Thank you

[SergeyTeplyakov]

I would be very happy if some one will pick this task and will start investigating it. Currently, I do have tons of stuff in ccrewrite world, and, unfortunately, don't have time to work on this one:(

[dotnetshadow]

Is there any further update on this? Can code contracts be used in asp.net core 1.0?

[SergeyTeplyakov]

I'll start investigating this issue. Maybe to get full support new .NET CLI tools should be aware of Code Contracts...

[michaelvolz]

Any news on that topic? I use code contracts all the time and would really miss to not having them in Asp.Net Core.

[thtp]

I'm joining the crowd. CodeContracts are widely used across our projects. And now, when it comes to migrate some of this projects to .NET Core, lack of CC causes many pain.

[SergeyTeplyakov]

@michaelvolz, @thtp I do understand the value of this proposal, but unfortunately, I don't know what to suggest:). Because this is a community project the only way to fix issue is to start working on it.

I can suspect that porting CC to CoreCLR is doable task but it will require significant amount of work. So let's form a group of people who will work on it, decompose it and start hacking! :)

[jirizaj]

Hi guys, are you planning to implement this? I love CC and I would like to use it in core projects. However displaying message when an exception from contracts is thrown is really annoying. Tkanks!

[raffaeu]

@SergeyTeplyakov if you are serious about it, I am in.
We can fork the GitHub project and start from there by logging all requirements?
What do you think?

[hcoona]

Is there any progress for supporting netcore apps?

[CyborTronik]

Would be nice at least to define a strategy for transition.
In one version could be delivered just PRE conditions, in other POST conditions and so on.
In this way would be easier for community to be involved there.
Otherwise there is too much work to do at once.

[ArtGangsta]

Anyone know why code-contracts aren't in common use?

[yaakov-h]

It was an academic/research project, never a mainstream solution.

[LYP951018]

Still no progress?

[hangy]

@yaakov-h Well - the CodeContracts project was always declared as a Microsoft Research project, but System.Diagnostics.Contracts.Contract is part of mscorlib and the official .NET Framework and .NET Standard 2.0. 😉 Because of that, it is a bit weird that MS made this a pure community project and did not care about supporting VS2017.

[yaakov-h]

@hangy The namespace was originally shipped as a separate assembly. IIRC, it was included in .NET Framework 4.0 with the expectation that Code Contracts would graduate from DevLabs and become a part of the core developer tools.

Considering that this had not happened by the time .NET Standard came into being, this really should have set off alarm bells.

[roji]

AFAIK the contracts namespace was included in netstandard mainly to preserve compatibility, i.e. so that programs with code contracts code would compile (even if contracts aren't enforced). That doesn't imply any sort of support or a bright future for code contracts.

[pi3k14]

@roji that was a strange definition of compatibility.
The same has been done with CAS, the net result is that you can't trust .Net Core/Standard assemblies (what else just compiles and doesn't provide any functionality) ...

[roji]

@pi3k14 I think saying that you "can't trust .NET Core/Standard assemblies" is a bit of an exaggeration... True, there are a few, well-known dead APIs which have been silently "disabled", but what's the alternative? Throw an exception and break all projects using these APIs? This at least provides an easy transition path to .NET Core/Standard, until you migrate away from Code Contracts, which again, is no longer supported.

I do agree it's unfortunate that Microsoft chose to implement Code Contracts - which was always a research project and never matured to an officially-supported product - in such a public, well-known namespace (System.Diagnostics), and that it was included in .NET Framework itself (but nuget wasn't really that widely-used back then).

[SunnyWar]

Michael Barnett commented · February 24, 2012 10:31 AM · Flag as inappropriate
Yes, I completely understand your point. But we (the Code Contracts team from Microsoft Research) have been working closely with the Developer Division on our tools. We think it is a great thing to have the ability to see our advanced research actually become reality. In this case, after long discussions, we felt that the best way forward was to get the Contract library introduced into the framework so that there would be a standard way for expressing contracts. By keeping the tools available through DevLabs, we have been able to respond to the many great ideas that have been posted on the Code Contracts forum and incorporate them in new releases at a much faster pace than we would if we were "in the box".

[weitzhandler]

Related comment: dotnet/runtime#23869 (comment).