Setup:
- .NET Core 3.1 console app
- Microsoft.CodeAnalysis.NetAnalyzers installed as a NuGet package
Problem:
I need to run code analysis from a command line interface to have it as a step in my CI (Continuous Integration) build process.
Ideally, I would like to have something similar to ESLint or TSLint running prior to building TypeScript applications and outputting all issues into console and not letting the build process going further in case of code analysis issues.
Any help is appreciated!
CodePudding user response：
.NET analyzers run on a build.
By default, only some rules are enabled: see Code quality analysis: Enabled rules. To enable all rules, you may set <AnalysisMode>AllEnabledByDefault</AnalysisMode> in your .csproj or a Directory.Build.props file in the project directory or above.
Most Diagnostics are reported with Severity Warning, so they will not break your build. But MSBuild also has the option to TreatWarningsAsErrors. I advice to only TreatWarningsAsErrors in Release builds (or non-Debug builds, depending on your preference), so that you can perform quick prototyping while coding and facilitate a satisfying TDD-cycle without worrying about each and every warning immediately during development. However, when you set your CI to build with Release Configuration, your pipeline will stop and fail if there is any Warning present (now treated as Error).
Example:
.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<AnalysisMode>AllEnabledByDefault</AnalysisMode>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis.NetAnalyzers" Version="5.0.3" PrivateAssets="all" />
</ItemGroup>
</Project>
CLI
dotnet build --configuration Release
If there are any Warnings present, they are treated as Errors in Release Configuration, and dotnet build will terminate with a non-zero exit code, failing your CI pipeline.
I have tested this example utilizing the .NET 5.0 SDK.
Keep in mind, that with the .NET 5.0 SDK and higher, the Microsoft.CodeAnalysis.NetAnalyzers are included in the SDK and may be enabled via <EnableNETAnalyzers>true</EnableNETAnalyzers>. If you prefer the NuGet package-based model for on-demand version updates though, you should not add the EnableNETAnalyzers property. And also keep in mind that the .NET 6.0 SDK offers a more fine-grained AnalysisMode: see MSBuild: AnalysisMode.
If you don't care about every Diagnostic from the analyzers and want to override the default severity of specific rules, you can add a Global AnalyzerConfig (.globalconfig) file to your project directory or above to configure the analyzers with.
.globalconfig (AnalyzerConfig)
is_global = true
# CA1062: Validate arguments of public methods
dotnet_diagnostic.CA1062.severity = silent
# CA1707: Identifiers should not contain underscores
dotnet_diagnostic.CA1707.severity = silent
# CA2007: Consider calling ConfigureAwait on the awaited task
dotnet_diagnostic.CA2007.severity = silent
This example is taken from one of my unit test projects, where I don't want to validate my parameterized unit test methods, where I use underscores in my unit test method names, and where I don't care about ConfigureAwait.
With AnalyzerConfig files, you can control the severity for each rule and force it to be either default, none, silent, suggestion, warning, or error. See Rule-specific options: Severity level.
Some rules offer additional configuration options. E.g. CA2007 can be only applied to code that produce a certain OutputType, such as a .dll, via:
dotnet_code_quality.CA2007.output_kind = DynamicallyLinkedLibrary
I'm not exactly sure where to stop. Let me know if this answers your question or if I should give some more details. Here is the link of the official documentation on that topic (it's super comprehensive): Code analysis: Overview of .NET source code analysis.
And remember, Roslyn is awesome!