0 to Analyzing, Writing a .NET Standard Roslyn Analyzer
This is our last week. Yep, the time has come to sunset this blog. The Coding4Fun blog's Goodbye post will be this Friday, December 22nd. Wednesday's post will be the final Round-up, listing the posts from December, 2017 and since I started with the blog, January, 2011 (That's going to be allot of posts! ;)
Today's post will be our last "content" post and it seemed fitting to highlight this great post from Andrew Lock.
Andrew has written up an awesome post and tutorial for creating a new Visual Studio Analyzer, using Visual Studio 2017, .NET Standard and Roslyn.
In this post, I give a brief introduction to Roslyn analyzers, what they're for, and how to create a simple analyzer in Visual Studio 2017. I'll show how to create a code analyzer that targets .NET Standard using the new Visual Studio 2017 (15.5) templates, and show how you can debug and test your analyzer using Visual Studio. As the code in Roslyn analyzers can be a bit complex, I'll look at the actual code for the analyzer in a subsequent post - this post just focuses on getting up and running.
Why create a Roslyn Analyzer?
I was recently investigating some strange bugs which would only sporadically manifest in an ASP.NET app recently. Long story short, eventually the issue was traced back to a
awaited. This was causing concurrency issues that were hard to spot in the code, as everything compiled correctly. For example
What are Roslyn analyzers
Analyzers are effectively extensions to the C# Roslyn compiler, which let you add extra warnings and errors to your code, in addition to the standard compiler errors. You can use these to enforce naming styles and code conventions, or to flag particular code patterns, such as the missing
awaitin the above code.
Creating a Roslyn analyzer
Up until recently, creating a Roslyn Analyzer that could be consumed anywhere was a bit of a chore. You had to install various extensions from the Visual Studio marketplace, and even then the project templates produced PCL projects, which requires a different build chain to normal .NET Standard projects. When I created my first analyzer, half the battle was converting the project to be compatible with .NET Standard.
1. Install the Visual Studio Extension Development Workload
2. Create an Analyzer with Code Fix
Debugging your analyzer inside Visual Studio
If you're new to working with the Roslyn compiler directly, then the code in an analyzer can be daunting. Lots of types with somewhat obscure names can make it difficult to get a foothold. For me, one of the best ways to get to grip with it was the ability to Debug my code as it was running in another instance of Visual Studio. That sounds like it would be a pain to set up, but it actually works out-of-the box, just press F5!
Testing your Analyzer and CodeFix
Roslyn is effectively a "compiler as a service". You can pass it a
stringcontaining C# code, and it will compile it, allowing you to ask semantic questions about the contents, including running your analyzer.
In this post I showed how to install the necessary components to build Roslyn analyzers, why you might want to, and how you can Debug and test your analyzers, using the default project templates. In the next post, I'll take a look at the code in the default analyzer template, and look at building the
awaitanalyzer described at the beginning of this post.