Problems associated with the use of Code Contracts with Roslyn compiler

It is no secret that a number of problems began to significantly creep up on Code Contracts technology after implementation of the Roslyn compiler. This time I will share my observations on the current state of the project and use the presented facts as a background to explain why, after almost four years, we chose to quit using Code Contracts in the project we have been developing.

From the point of view of C# code processing, the introduction of the Roslyn compiler was a revolution. It has resulted in a number of changes regarding the subtleties of IL code generation for a number of statements. As it has already been pointed out, such changes took a great toll on the technology, that so profoundly interferes with the compilation process results. These problems have affected us personally. We have been using Code Contracts in our project nearly from its very beginning i.e. since fall of 2012. Of the entire Code contracts family, we have been specifically using ccrewrite that, as already mentioned, checks the contract fulfillment during the application execution, as well as the IDE Visual Studio extension.

Since then, we have utilized the contract programming rules to create a number of components, which brought invaluable benefits to us. In spring of 2016 we began the migration process towards the use of Visual Studio 2015 with Roslyn compiler. It soon became clear that the configuration brings to light problems associated with the use of Code Contracts:

    • it turned out that in certain situations, during the execution, the implicit contracts (ie. defined by if(! ...) throw ArgumentException() statement; at the beginning of the method, instead of the explicit Contract.- Requires call) caused the occurrence of an unjustified NullReferenceException. This looks like some kind of incarnation of the problem reported in [Issue 191];
    • problematic for very peculiar reasons, it revealed the depletion of certain attributes from external libraries (in our case it was a attributes from ASP.MVC!) for decorating our components - in some cases it caused compilation errors connected to the visibility range of the program elements. Most likely this is the problem already reported in Issue 273;
    • it turned out that the creation of table instances in the contract contents causes errors during the compilation process (problem reported in Issue 221), this regards the statements an example of which is presented below;

Initiation of table in Code Contracts

public void SomeMethod(double parameter)
    Contract.Requires((new []{ 1.0, 1.1, 1.2 }).Contains(parameter));

    • the presence of the Visual Studio extension resulted in the occurrence of StackOverflow- Exception, during the generation of tooltips for certain components for which the contracts have been defined. This, of course, caused the closing of the entire IDE process - it was necessary to uninstall the whole problematic component.

We noticed that the Code Contracts version provided by Visual Studio Gallery (which we used) is dated 28 July 2015 (this has not changed yet. See CC in Visual Studio Gallery). Taking into consideration the number of error corrections up to date, the version is really old. We decided to acquire the source code of the project and compile it from the sources - this turned out to be not an easy task. It quickly became clear that compiling the project using Visual Studio 2015 is now impossible - which is a widely experienced problem. However, with the aid of an older IDE version (2012) with a few changes to the configuration, we were able to finally compile the source code. It turned out that some of the problems that were troubling us have been resolved, however a number are persistent until this day. In addition, we noticed that the duration of the compilation process for our application has increased manifold. Thus, the use of Code Contracts remained problematic, as it would require a number of changes to the application code, and would involve considerable inconvenience connected to the compilation time increase, that had already been long, which we could not afford.

A brief history and current state of the project

Disturbed by the above facts; I decided to perform a small investigation of the Code Contracts current status. Bear in mind that, for the most part, the information presented in this paragraph is of speculative nature.

The beginning of the Contract Code project can be roughly dated 2008, when it was created as part of Microsoft Research team which included, among others, Francesco Logozzo, Manuel Fahndrich and Mike Barnett. It should be emphasized that many members of this team boast academic degrees and fairly large numbers of publications on, among others, the theory of programming languages. The strong, theoretically prepared team made it possible to create a decent and complex solution within the timespan of few years, described in this document. The activity of the project members at that time was very intense - a number of documents, tutorials and video conferences dating back to that period can be easily found. However, since 2011, the activities around the project have gradually decreased. Based on the short investigation of the Code Contracts project task team presence in social media, it can be concluded that somewhere around 2013, most of them either terminated the cooperation with Microsoft and have not participated in the development of the Code Contracts since. It seems that currently the only person from the Microsoft website associated with the project is Sergey Teplyakov, who still remains active in a small community centered around the Code Contracts. Nonetheless, as he himself admits, his interest and involvement in the project is merely private, as the Code Contracts does not have official support from Microsoft. He also states that the scale of the project, the number of currently known bugs and the pull request to embark on are beyond the ability of one person.

Knowing the context of the revolution around the .NET that involved the opening of the source code, presenting .NET Core and changing the compiler to Roslyn, we suspect that the executives of Microsoft Research have lost their interest in the project and ceased to fund it, which resulted in the team breakup. The source code of the project is now made public and available on Github, and the community around it still presents certain activity. And that is the current state of the Code Contract project that has been hampered by numerous problems.


At this point, I cannot refrain from a quite sad conclusion that a great tool, whose reliability has long aided our project, is now almost completely useless - or has even become a problem in itself. Due to this, there are no indications whatsoever regarding any possible improvement of its state, as the development of the solution has been abandoned by Microsoft Research, and even though it has been made available as Open Source, the cost of the project’s maintenance is too high to expect any active involvement of the small community around it. There is no real alternative to .NET contract programming technology in relation to Code Contracts. In the light of all these incredibly sad facts, we withdrew from the idea of contract programming for the preparation of our project and with great regret resigned from using Code Contracts. Considering the instability and the uncertain future that currently characterize the tool, its current use, along with Roslyn compiler, in any serious project is in my opinion impossible.


code contracts, software, software development, Roslyn compiler, Visual Studio
Wojciech Stelmaszewski

Would you like to learn more? Contact us.