As a .NET resolution grows, the time spent on Roslyn analyzers throughout compilation will increase. I’ve witnessed an online resolution the place the execution time of the Roslyn analyzers was merely absurd. Particularly, the ratio was 70% of the time spent on the Roslyn analyzers and 30% on the remainder of the compilation. The full construct time was about 2 to three minutes relying on the machine’s specs.
Such a compilation period has a direct affect on three factors:
- The productiveness of builders, whose time spent ready every day can attain important values.
- Metrics associated to supply and steady deployment. A slower compilation means longer validation instances for pull requests and launch publications.
- The satisfaction and motivation of builders, who’re annoyed by ready with every code change.
The compilation period of a .NET resolution may be justified by a number of features, together with the quantity of code, dependencies between initiatives, coupling between initiatives, and so forth. On this first article, we’ll focus solely on the affect of Roslyn analyzers on the compilation time. After studying this text, it is possible for you to to determine their affect in your .NET options and take motion to cut back it, with out neglecting the standard and assurance they supply.
The standard suspects
Earlier than going any additional, let’s take a look at some well-known Roslyn analyzers that will already be enabled in your options.
.NET contains Roslyn analyzers for code style and quality. These are the foundations with codes beginning with CAxxxx, CSxxxx, and IDExxxx. Relying on the goal framework, a subset of those analyzers is enabled by default. The AnalysisLevel property may be modified to incorporate extra or fewer guidelines.
A number of well-known NuGet packages akin to xUnit.net, FluentAssertions, StyleCop, Entity Framework Core, and others embrace by default a major variety of Roslyn analyzers. They assist you adhere to the conventions and greatest practices of those libraries.
The issue is that you could be not want all of the evaluation guidelines included in these packages. Just lately, I grew to become conscious of a latest .NET resolution that had a transitive reference to Entity Framework Core, whereas the latter was not used. After evaluation, I found that the Entity Framework Core evaluation guidelines added a second to the overall compilation time. Let’s learn how I proceeded to determine this downside.
Analyzing the affect of Roslyn analyzers on compilation time
To start, you will want to put in an exterior instrument created by Kirill Osenkov. Kirill is an absolute professional in MSBuild and a Principal Software program Engineer at Microsoft. He developed a instrument known as MSBuild Structured Log Viewer, which lets you learn compilation logs generated by MSBuild. Observe the hyperlink and set up it.
Secondly, you’ll need to enable analyzer reporting during the compilation of your initiatives. This may be completed by including this line to your challenge. Ideally, it is best to add it to all of your initiatives in your resolution, and essentially the most environment friendly method to do that is to make use of a Directory.Build.props file on the root of your resolution.
<Venture>
<PropertyGroup>
<ReportAnalyzer>true</ReportAnalyzer>
</PropertyGroup>
</Venture>
Thirdly, it’s essential compile your resolution and generate a *.binlog file. You are able to do this from the command line with the next command:
dotnet construct /bl
/bl is shorthand for /binarylogger. As soon as the compilation is full, it is best to have a *.binlog file within the root folder of your resolution or challenge. Double-click this file to open it with MSBuild Structured Log Viewer.
Rider customers are in luck as a result of they need not run any CLI instructions. The combination of MSBuild Structured Log Viewer is included. Proper-click on a challenge or resolution, select “Superior Construct Actions,” and click on on “Rebuild Answer with Diagnostics” for a complete resolution, or “Rebuild Chosen Tasks with Diagnostics” for a number of particular person initiatives. The log viewer will mechanically open after the compilation.
Figuring out the Roslyn analyzers with essentially the most affect
If you open a binary log file created with the ReportAnalyzer property set to true, MSBuild Structured Log Viewer shows an Analyzer Abstract part on the backside of the principle tree view. This part may be expanded, and you’ll then have an in depth evaluation of every Roslyn analyzer, from the slowest to the quickest. Every Roslyn analyzer will also be expanded to show the person guidelines that had been executed, with their execution time, and in addition within the order from slowest to quickest.
On this instance challenge (which is actual), we are able to see that some Roslyn analyzers have a major affect on compilation time. Particularly:
- StyleCop has a huge effect, with greater than a minute and a half.
- FakeItEasy has a substantial affect of over 30 seconds.
- AsyncFixer provides nearly 30 seconds.
It is very important make clear that code evaluation is mostly executed in parallel, which implies that the overall execution time of Roslyn analyzers isn’t the sum of every rule.
An skilled developer would possibly surprise, for instance, if AsyncFixer is admittedly needed. The latest variations of .NET (6, 7, 8) embrace increasingly more Roslyn analyzers geared toward rising code high quality, notably with using async/await. Nevertheless, few folks know that sure guidelines have to be activated with the AnalysisLevel property, for instance:
<PropertyGroup>
<!-- Permits all .NET built-in evaluation guidelines that come from the .NET 6 SDK -->
<!-- Merely a must have for initiatives concentrating on .NET Commonplace 2.0 because the default stage could be very low -->
<AnalysisLevel>6.0-All</AnalysisLevel>
</PropertyGroup>
Disabling pointless Roslyn analyzers
After you have recognized the Roslyn analyzers which have essentially the most affect on compilation time, you are able to do some analysis and determine as a workforce if sure guidelines are needed or not. Should you determine to disable some guidelines, the quickest method to take action is to create an .editorconfig file on the root location of your resolution. On this instance, I disable the StyleCop evaluation rule SA0001, in addition to a number of guidelines from the AWS SDK which is referenced transitively in my challenge, however which I don’t use.
[*.{cs,vb}]
dotnet_diagnostic.SA0001.severity = none
dotnet_diagnostic.SecurityTokenService1000.severity = none
dotnet_diagnostic.SecurityTokenService1001.severity = none
dotnet_diagnostic.SecurityTokenService1002.severity = none
dotnet_diagnostic.SecurityTokenService1003.severity = none
dotnet_diagnostic.SecurityTokenService1004.severity = none
Confer with this Microsoft documentation to learn more about how to suppress warnings from Roslyn analyzers.
Compile manufacturing builds sooner
In case your workforce works with pull requests to merge your options into the principle department, there is a good probability you’ve high quality gates in place that guarantee your challenge compiles efficiently, your assessments are inexperienced, there are no warnings and errors, and so forth. This often implies that the code in the principle department is of top of the range and may probably be deployed to manufacturing.
Contemplating that the code evaluation guidelines have already been run throughout CI, it might not be essential to burden the compilation time of the manufacturing deliverable with further code evaluation. You possibly can merely disable the execution of Roslyn analyzers by modifying the dotnet construct or dotnet publish command with the RunAnalyzers property set to false:
dotnet construct -c Launch -p:RunAnalyzers=false
In my instance challenge, disabling code evaluation reduces the compilation time from ~2 minutes to lower than 50 seconds!
In case your workforce has a really excessive velocity and also you deploy to manufacturing a number of instances a day, this may have a major affect in your supply and steady deployment metrics. Should you use a cloud supplier to compile your Docker photos, this may additionally scale back your prices.
Conclusion
On this first article of a sequence in regards to the optimization of the compilation time of .NET options, we have now seen the right way to determine the Roslyn analyzers which have essentially the most affect on compilation time. We have now additionally seen the right way to disable code evaluation guidelines that aren’t needed, and the right way to disable the execution of Roslyn analyzers in the course of the compilation of manufacturing deliverables.
I hope this text has been useful to you. Be at liberty to react within the feedback or contact me on Twitter @asimmon971.
