Roslyn Analyzer Performance

TL;DR

Do you write Roslyn analyzers? Ever wondered what impact they have on your compilation times? Here’s how you can get the stats!

To get the numbers one can use the ReportAnalyzer MSBuild property, that gets passed in to the C# / VB compilation tasks. It’s the MSBuild equivalent of the -reportanalyzer C# compiler command line switch.

I usually use it in combination with the -bl MSBuild switch, so I can inspect the output with the the excellent MSBuild Binary and Structured Log Viewer.

msbuild Your/Project.csproj /p:ReportAnalyzer=true /bl:out.binlog

After the build is done, you can find the relevant bits right after the Csc task

Backstory

I was looking into increased build times (see image above) after introducing some new analyzers, and I couldn’t find a good reference for this kind of investigation.

This is another Stack Overflow .NET Core migration war story.

As we’re working on porting Stack Overflow to .NET Core, there will be a temporary phase, where some of the applications in our codebase will run on ASP.NET MVC, while others will already be ported to ASP.NET Core (see my previous blog post). For our domain logic and data models this means that they will have to be compiled against both. The most simple way to achieve this is if they don’t depend on ASP.NET at all. We’ve worked hard on this decoupling but we were still left with the occasional IHtmlString reference, etc. Some ASP.NET references had to stay, but we didn’t want them to grow unwieldy. So we created Roslyn analyzers that check for ASP.NET usage, and fail the build if they find an usage that is not explicitly opted in (e.g. by using #pragma warning disable ASPNETUSAGE or via SuppressMessageAttribute). Developers that do feature work get a nice error at build time, and a squiggly in their editor, whenever they accidentally introduce a new ASP.NET reference into the shared library. This prevents them from stepping on the toes of the developers working on the port.