Project Update to .NET Compiler Platform (Roslyn): Better Late Than Never

So I was tasked by our client to update all our projects due to a planned move to .NET 4.8. There were talks that Azure will finally roll out the said .NET version to app services and I was given until the 14th of July to update all projects. It sure is laborious, considering that I’m handling about five separate projects by myself. Trust me, I don’t even understand how I can handle that much. But that’s not the point.

So yeah, the update. Because I love seeing things on fire and I want to hurt myself so badly, I started with the hardest project to maintain.

I just did the usual stuff that you do with updates. You change the target framework version, reload your NuGet packages to see if anything broke after the switch, and fix the dependency issues that you find.

I was expecting a laborious but straightforward update. After all, it’s in .NET 4.6.1. It’s not very old. Should be pretty simple, right? Well… not really.

While I was fixing the dependency issues, I encountered a weird issue. Whenever I try to update all packages, I get this error:

I thought maybe I’m just missing certain references or perhaps I just have to do it little by little. I thought that’s not a bad idea, thinking that certain packages started to require other libraries after I updated them. So I did.

After fixing the references and updating the packages batch by batch, I’m still getting the same error. I had no idea what’s happening. As any self-respecting developer would tell you, this is the right time to check StackOverflow. Sure enough, someone already encountered it and shared their solution. According to vendettamit, the issue was due to the update from an older .NET version to .NET 4.8, which involves a switch from MSBuild to Roslyn.

So what exactly is Roslyn? Roslyn is a .NET compiler for C# and VB.NET. A lot of things can be said about it that I’m not even sure if I can explain it properly. But the most notable thing about it (as I see it anyway) is how it propelled Visual Studio and .NET development in general to greater heights. Roslyn provides an extensive set of tools that directly interacts with the compiler which can provide vital information about the code that was previously out of the developer’s reach. As the .NET Compiler Platform SDK documentation explains it, “opening up the black boxes and allowing tools and end-users to share in the wealth of information compilers have about our code”.

Roslyn gave developers more control over the way they code by having special APIs that provide more sophisticated code analysis capabilities, which helped improve the code analysis tools that developers have. What’s even more awesome is that the Roslyn implementation is open source, so you can review how the compiler does it, provided that you have a substantial amount of time reviewing compiler code, that is.

Going back to the issue at hand, what exactly is happening? If you will look at the project file (the one with the .csproj extension), you will probably see two imports.

Microsoft.Net.Compilers

and

Microsoft.CodeDom.Providers.DotNetCompilerPlatform

In my case, it’s like this:

and this:

To solve the issue, I followed vendettamit’s suggestion and deleted all lines mentioning Microsoft.Net.Compilers. This can be done in Visual Studio by unloading the project and editing the .csproj file by hand. As you can see, there are mentions of the package on both Import and Error tags. So I removed them, saved the changes, and reloaded the project.

After reloading the project, I’ve tried updating the packages again and it worked like a charm. The packages loaded normally and the project builds as though nothing happened. I even tried deploying the entire thing and it just works.

The answer from StackOverflow was fine and dandy and fixed the problem for me. But I still want to know what happened here. I found the answer after reading a little bit.

If you look at the NuGet page for Microsoft.Net.Compilers, you will see that the entire thing has been deprecated and was replaced by Microsoft.Net.Compilers.Toolset. According to the package’s description, it supports .NET 4.7.2+. So I guess it will be the same case regardless of version as long as I upgraded to 4.7.2 and above.

This experience has made me realize how far .NET has gone since I became a developer. It was good then and it’s still getting better.

Leave a Reply

Your email address will not be published. Required fields are marked *