What does the Future of Code Contracts Look Like?

[lundmikkel]

I'm a big fan of Code Contracts and what it allows me to do. I've been using CC for almost five years now, and I would hate not using it. I've used it for both academic and commercial projects, and I feel naked, when I don't used it.

I am, however, a bit afraid of the project's current status. There seems to be extremely little activity: only two commits were made within the last two and a half months; there are 144 open issues, where the newest ones are hardly tagged or even commented (my own issues have gotten almost no attention); there are more and more pull request, many only commented by the author; the last release candidate was released in January, and only 31 commits have been made since then.

I would like to know what to expect in the future. What does it look like for CC? Should I expect updates and to be able to keep using Code Contracts or should I rather look for new tools?

@SergeyTeplyakov, @sharwell, @tom-englert, @hubuk, @yaakov-h: what are your commitments to the project? I can see you have all done a lot for the project after it was open-sourced, but few of you have been active this year. Have you all left, or are there still maintainers of the project?

I hope, I will get some answers, so I don't have to stay in the dark. This is a great project, and I would hate losing it.

[tom-englert]

My relation to CC is the same as yours, I would not want to miss it.

However the time I can spent contributing to this project is very limited, and as long as it satisfies the "Works for me" criteria, priority to improve it is low, that's why there is no recent activity from my side.

[yaakov-h]

I'm quite worried about the future of this project.

There's little activity from the owners, and it appears to have been defunded and largely abandoned within Microsoft, with Francesco uploading the project to GitHub at the same time he left Microsoft (if I have gotten my LinkedIn-stalking correctly). It doesn't seem like there's much future in it.

That said, my projects do depend on it and I'm seriously considering forking the project just to get some level of control over the release schedule. I've had to maintain a private fork already just to get decent VS2015 support, and was hoping to drop it when 1.10 was released, but it's been virtual radio silence since RC1 and RC1 contains a blocking bug, now fixed in master.

My long-term hope is that non-nullable reference types in C# 8 will largely replace the need for Code Contracts.

[petergummer]

On 2 May 2016, at 10:12, Yaakov notifications@github.com wrote:

My long-term hope is that non-nullable reference types in C# 8 will largely replace the need for Code Contracts.

Non-nullable reference types in C# might indeed spare us from needing to write not-null assertions; but although these represent a large proportion of contracts, they won’t replace contracts altogether.

The Eiffel programming language has had contracts forever, but the need for contracts did not go away when Eiffel eliminated null-reference exceptions a few years ago. (In Eiffel, a null reference exception is known as a “void target call”. The mechanism that eliminates void target calls from Eiffel is called “void safety”; ironically, they got the idea for void safety from work done about 10 years ago at Microsoft Research.)

Peter Gummer

[wuestholz]

Over the last few months, @mariachris and I have been working on a new feature for the static checker that makes it possible to perform bounded static analysis. Bounding the analysis can improve precision and performance (by up to 8x in our experiments with msbuild), but might miss bugs. It is meant to provide faster feedback to users (e.g., in the IDE) with fewer spurious warnings. See #412 for some more details. We would be happy to hear from users that give this a try!

[ndykman]

Great news on the static checker. I know progress is hard, and C# 6 did add a lot of changes that affected the rewriter and static checker, and it takes time to work though these issues. The hard part is both of these tools are highly specialized pieces of software with complex research ideas behind them. I think many of us want this to become a core piece of the .Net toolchain, but this is a long road. Personally, I'd take a job at MSR to try to make this happen in a heartbeat, but the reality is that the transfer of research technology to commercial applications is very difficult.

[SergeyTeplyakov]

@lundmikkel Sorry for late response, hope latter is better than never.

There is few interesting things are happening but never got finished yet: We're moving the repo out from Microsoft org to dotnet org to reduce "bus factor" and add more official maintainers who can work and drive project further.

As for my personal involvement I was mainly focused on rewriting stuff and joined the project as my personal one with some support from my team to get VS2015 support. I still have interest in this project myself and my team is still heavily relying on Code Contracts (we're not using static checker any more but we still using ccrewrite).

I really want to keep working on the project and will try to keep an eye on it by merging PR's more frequently, but the problem with this project is that it takes much time just to review a minor PR. Any changes to ccrewrite could have significant effect to existing customers and even changes to BCL contracts can breaks them as well.

All of this affects overall activity that is happening in this repo an no official support complicates it a lot.

For me this is a personal project, just happens that I'm a big fan of Code Contracts (like you and many other guys), but I was lucky enough that I joined the team at Microsoft that is uses it extensively and I had a chance to be involved in it as a new maintainer.

I would try my best to keep working on it and react faster on new bugs and pull requests. I'm still committed to fix bugs in ccrewrites if they're critical or implement some features (like I did with new async postconditions).

[aarondandy]

Thanks for giving us all an update.

[ContentsMayVary]

I think there's a huge "silent majority" who rely on Code Contracts but who don't post here. For example, I rarely post, but we have a million-line codebase that relies extensively on Code Contracts. If they stopped working in the next release of Visual Studio/.Net, we'd be stuffed.

[roji]

Note that code contracts have already "stopped working" if you need to support .NET Core. Personally I just dropped code contracts in a significant project because it's not possible to rely on its continued evolution.

[lundmikkel]

@roji I'm having the same issue. I just did my master thesis, where I developed a library that relies heavily on CC. After just four months, I'm considering removing it from the library again – at least for preconditions. I like the framework a lot, but I'm afraid of basing my projects on it, as it would require a lot of extra work to remove that dependency. I'm torn.

[roji]

@lundmikkel I really understand what you're going through. There's a case for at least partially sticking with CC.

For preconditions, as long as you're using the precondition style which doesn't require rewriting (i.e. with plain old ifs and Contract.EndContractBlock()) things are more or less OK - checks will always running. Postconditions and invariants are a unique CC feature, so there's no way to "transition away" from them to anything comparable. Assertions/assumptions are becoming problematic - continuing to use CC for them means these checks are ignored under .NET Core.

So I'd say that if it should be OK to continue with CC for a while, but not rely on it for preconditions or assertions/assumptions. You get everything in .NET Framework, and in .NET Core at least you still have preconditions and assertions/assumptions.

[Worthaboutapig]

Not much going on here still :(

Can I confirm that Code Contracts doesn't work with .NET Core? And is it intended to be supported? (If not, then it's basically dead, as everyone is pushing that way.)

[TAGC]

So I've just about started to port projects that target the .NET Framework to .NET Core. They're heavily reliant on Code Contracts. I come here and find that Code Contracts support for .NET Core is practically non-existent. Awesome. 💯

[roji]

For people upset about the state of Code Contracts, it's worth reminding recalling that this was a research project that never became an official supported product... The choice to use it carried the risk this would happen.

Also, AFAIK since it was open-sourced on Github there's nobody left at Microsoft working on it in an official capacity. Either the community picks this up or it will stagnate, as is already happening.

[yaakov-h]

@roji Code Contracts was originally made available under a Commercial Licence. This implies it's fit for use in a commercial environment, as opposed to being an unsupported research/PhD project.

[roji]

@yaakov-h I'm not sure a licence implies anything about support etc. - it's just a license - actual products (like .NET Framework) have clear support lifecycle commitments. Code Contracts was always hosted on Microsoft Research, which in itself should already mean something.

In any case, it's not really a discussion worth having... CC is an open source community project now.

[DiskCrasher]

An OSS project that's essentially DOA. It's unfortunate that MS still publicly advertises CC when there is no official support for it. I wouldn't recommend it to anyone at this point.

[TAGC]

@DiskCrasher or anyone else, any suggestions for good replacements for Code Contracts? What sort of libraries do you use instead for e.g. precondition checking, invariant validation, assertions, etc.?

[magol]

I'm using ReSharper annotations to notated notnull on parameters and return values. It don't cover all features in code contract, but I don't miss anything important.

[roji]

Same here, at least for null analysis I find Resharper superior to CC (especially due to the realtime analysis inside VS).

[mayconbeserra]

Hi @roji and @magol ,

Is there any other option (Code Contracts) for .net core running on Linux or Mac? (I don't have a windows at the moment).

Regards,

[roji]

@mayconbeserra I'm not sure, but I think Jetbrain's project rider uses the same engine as R#, and may therefore perform the code analysis (e.g. null checks). It's worth a try.

[DiskCrasher]

And don't expect anything new with regards to CC in C# 7.0 either. See Mads Torgersen's comment in the link here. It's essentially dead.

[TAGC]

A lot of you guys mention Resharper annotations but:

1. Resharper's a paid tool and will only benefit those that opt in to using it
2. I assume it only aids in pointing out potential issues during development, but can't actually be used to validate arguments in production? I.e. useful only for precondition checking on internal and private methods?

[roji]

@TAGC,

Resharper's a paid tool and will only benefit those that opt in to using it

Code Contracts are just as "opt-in" as Resharper - if you don't install CC your assembly doesn't get rewritten and the contracts have no effect. And obviously there's no static analysis. It's true that R# is paid, though.

I assume it only aids in pointing out potential issues during development, but can't actually be used to validate arguments in production? I.e. useful only for precondition checking on internal and private methods?

It's true that R# is purely a static analysis tool, and doesn't add code that enforces non-null - in other words, adding R#'s [NotNull] attribute doesn't add a runtime check for null. However, if you configure static nullability checks to trigger compilation errors (this can be done on the build server too), you get pretty good protection.

It could also be argued that in a lot of cases, if a method's contract doesn't allow a parameter to be null, then there's not much use in checking for it and throwing (as opposed to simply having an NRE thrown from inside) - checking and throwing may give a clearer exception but not a whole lot more. I admit that this argument doesn't always hold.

[tom-englert]

Since the future of CC is unclear, I decided to go with R# in parallel, since we already use R#.
For anyone who's interested, these two tools will help in migration:

A code fix provider that adds R# annotations for all simple not-null contracts:
https://visualstudiogallery.msdn.microsoft.com/8005d228-9f16-4a78-906e-366e919af8e5

A VS extension to turn contract static analysis or run time checking on or off on the fly without touching all projects:
https://visualstudiogallery.msdn.microsoft.com/8824a4d1-1a86-4a8d-905d-3d12a9681dcc

[NameOfTheDragon]

Thanks for that Tom. The VS extension sounds really useful, I will have to try that.

It’s a shame that Code Contracts wasn’t pushed through by Microsoft, it was and is an excellent technology that doesn’t really have a parallel in any other product. The R# code annotations go some way but are necessarily somewhat limited by the fact that they are just attributes that only inform the editor and have no real effect at runtime. I prefer to handle the “not null” thing by never ever accepting or returning a null unless I absolutely have to. I use a Maybe to represent an object that may or may not have a value. I use a relatively simple interpretation, here’s an example: https://bitbucket.org/tigra-astronomy/ta.uwp.devices/src/ca495dda2a4a6ac30d2e25597db3a6fa8cd19900/TA.UWP.CoreTypes/Maybe.cs?at=master&fileviewer=file-view-default

Perhaps the best alternative I’ve found that has an effect both at runtime and compile time, is PostSharp (https://www.postsharp.net/). PostSharp is an Aspect Oriented Programming (AOP) framework and tool chain. Not only does this have some built-in contracts (for example “StrictlyPositive”, “Required”, etc.) but you can author your own, so you could for example produce domain specific contracts (aspects) that could verify the state of complex business objects or data models. The contracts are applied as attributes in much the same way as for ReSharper, but PostSharp postprocesses the output assemblies and injects code that will execute at runtime. There’s a free version that you can try out on small projects. And of course you get all the other goodies like the threading and logging pattern libraries.

Best regards,
Tim Long

From: tom-englert [mailto:notifications@github.com]
Sent: 12 November 2016 15:43
To: Microsoft/CodeContracts CodeContracts@noreply.github.com
Subject: Re: [Microsoft/CodeContracts] What does the Future of Code Contracts Look Like? (#409)

Since the future of CC is unclear, I decided to go with R# in parallel, since we already use R#.
For anyone who's interested, these two tools will help in migration:

A code fix provider that adds R# annotations for all simple not-null contracts:
https://visualstudiogallery.msdn.microsoft.com/8005d228-9f16-4a78-906e-366e919af8e5

A VS extension to turn contract static analysis or run time checking on or off on the fly without touching all projects:
https://visualstudiogallery.msdn.microsoft.com/8824a4d1-1a86-4a8d-905d-3d12a9681dcc

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/409#issuecomment-260129353, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABNbCvtbCsw0X6F7VZSykWcFcmPHrHT4ks5q9d6TgaJpZM4IR1AO.

[tom-englert]

I would prefer https://github.com/fody over PostSharp, it's open source and has much more plugins.

[Ralstlin]

In the meantime for .net core I am using this:

public static class Contract
{
        public static void Requires<T>(bool result, string message) where T : Exception
        {
            if (!result)
            {
                T ex = (T)Activator.CreateInstance(typeof(T));
                typeof(T).GetField("_message", BindingFlags.NonPublic | BindingFlags.Instance).SetValue(ex, message);
                throw ex;
            }
        }
}

I Updated the code above as someone pointed out that some exception constructor with a single string is not always the message, for example: https://github.com/dotnet/corefx/blob/master/src/System.Runtime/ref/System.Runtime.cs#L199

[damageboy]

Hi All,
I know this is a dead project to many of you, but I'm seriously thinking about using this:

https://github.com/AArnott/CodeGeneration.Roslyn

To provide most of CodeContract's runtime checking by re-writing the c# code @ compile time....

I wanted to know if anyone is still interested in this, just to gauge the general interest that may still remain in using CodeContract runtime-checking (only), the features that I think it would be relatively do-able to support are:

• Preconditions - Contract.Requires / Contract.Requires<TExcetpion>
• Legacy Pre-conditions - Contract.EndContractBlock()
• Post conditions - Contract.Ensures / Contract.EnsuresOnThrow
• Object Invariants - via [ContractInvariantMethod]
• Interface Contracts - via [ContractClass(typeof(IInterfaceContract))]
• Contract inheritance

By "relatively do-able" I DO NOT mean to say that it can be done within a weekend, but I mean that unlike code-contracts which works on the MSIL level and is extremely sensitive to compiler/msil changes that happen from time to time, source-level rewriting via Roslyn can be relatively easy to inject... (relative being the key operative word here).

Anyway, I don't mean to layout the whole thing here, but just wanted to know if anyone is still interested in this sort of feature set...

[MarkDerman]

Hi @damageboy

I'm a long time fan of code contracts, and am frustrated as well as a bit perplexed at its apparent demise in VS2017...?!?!?

For me, assertions \ design by contract have been a key tool for years for achieving high levels of correctness to spec and robustness in challenging domains, ever since I absorbed the fundamentals from Bertrand Meyer's "Object Orientated Software Construction" many years back...

I also have never made much use of the static checker, and would be very interested to look at creating a basic runtime implementation of pre-conditions, post-conditions, class invariants, and interface contracts as this would meet 99% of my needs.

I have pondered the design challenge created out of having moved more towards a build-once deploy many times approach to dev in general, and what that means for code contracts and not producing different builds for DEV\QA\LIVE. i.e. Maybe a fresh approach is needed that uses runtime config to toggle pre-condition, post-condition, invariant handling, etc config (on\off\param checking only\etc).

So, yes, I am very interested, keen to chat about it, and potentially also help out.

Cheers,
Mark

[damageboy]

@MarkDerman thanks for you comments.

One thing I also forgot to mention was that with source-level rewriting for CC I can see additional upsides:

• Async re-writing becomes much easier to handle, and more robust. Today, I have a solution with 80 projects where code contracts needs to be turned off in about 40 of them because of various failures to handle async methods
• Running on Linux/OSX might actually become feasible...

[tom-englert]

@damageboy an interesting approach - however for me the killer feature is the static checker.
Runtime checks are only nice to have, because if the static checks work well, they never trigger. (I even can't remember when I have seen the last runtime check throwing)

So if someone would be interested in re-writing the static checker as a Roslyn analyzer, I would definitely opt in.

[yaakov-h]

Someone's rewriting the null checking for C# 8.0... the rest is IMO just a nice-to-have but nowhere near as critical. 😄

[lundmikkel]

It's nice to see some activity here again :)

[Vlad-Herus]

For anyone trying to get code contracts working in VS2017 - use this nuget package (github).
Note:
1 There's no tab for project properties so you'll have add those manually.
2 If you have code contracts msi installed you'll have to copy .targets file for msbuild 15 from nuget package folder to program files folder. (VS should give you path in the build error message)
3 Not sure if this supports .net core projects, but for older .net framework projects works just fine.

[Igorbek]

ah, didn't expect to see this announcement here @VladimirUAZ in a couple of hours since I published this package :) thanks.
Just a heads up, I'm gonna work soon on a new version of this package that will support upgrading CodeContracts independently. So, basically, it will include dependency on the DotNet.Contracts and would only provide MSBuild bindings.
Please use it, any feedback is very welcome.

[baSSiLL]

For those who decided to migrate away from Code Contracts there's a nice tool for converting pre-conditions to if-throw and removing all other contracts-related code.

https://github.com/deniszykov/code-contracts-remover

[ndykman]

Honestly, I think the best hope (and it's small) the overall project has is to get features to make Roslyn aware of Code Contracts. Unfortunately, with nullable reference types, a lot of people think the issue is solved, and ignore the much larger picture of supporting contracts in a language. Also, it ignores that the nullable reference types proposal is pretty imprecise compare to Code Contracts, but without getting stuff on the Roslyn roadmap, it's pretty moot.

I'm tempted to actually just make a bigger proposal for object signatures for C# 9.0 to gauge where people are on this.

[roji]

@ndykman and others, in case you missed this there's dotnet/csharplang#105, for integrating a contract syntax similar to Code Contracts in the language.