Qodana Community for .NET

The Docker image for the Qodana Community for .NET linter is provided to support different usage scenarios:

Running the analysis on a regular basis as part of your continuous integration (CI-based execution)
Single-shot analysis (for example, performed locally).

You can run the Qodana Community for .NET linter using two methods. Qodana CLI is the easiest method. If necessary, check the installation page to install Qodana CLI. Alternatively, you can use the Docker commands from the Docker image tab.

Quick start

Use DotSettings to configure code inspections

If you have previously worked on the target solution with ReSharper, you may have already configured code inspections settings. If so, InspectCode will find your custom settings in .DotSettings files and apply them. If there are no settings files, then the default severity levels will be used for all analyses. Besides custom severity levels for code inspections, InspectCode will look for the following settings in .DotSettings files:

Whether the solution-wide analysis is enabled
Naming rules (this can only be configured using .DotSettings files)
Files, folders, and file masks excluded from code analysis
Files, file masks, and regions with generated code, where the code analysis is partly disabled (this can only be configured using .DotSettings files)
A place where the code analysis engine should store caches. You can specify it on the Environment | General page of ReSharper options
Target languages (ReSharper | Options | Environment | Products — Features)

To configure InspectCode on a CI server, make all configurations locally with ReSharper, save the settings to the Solution Team-Shared layer, and then commit the resulting YourSolution.sln.DotSettings file in the solution directory to your VCS. InspectCode on the server will find and apply these settings.

By default, InspectCode also runs Roslyn analyzers on the target solution. If you want to disable Roslyn analyzers, you can do it in the solution's .DotSettings file, for example:

                <wpf:ResourceDictionary xml:space="preserve"
                      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                      xmlns:s="clr-namespace:System;assembly=mscorlib"
                      xmlns:ss="urn:shemas-jetbrains-com:settings-storage-xaml"
                      xmlns:wpf="http://schemas.microsoft.com/winfx/2006/xaml/presentation">

                    <!-- Enable/disable Roslyn analyzers and Source Generators -->
                  	<s:Boolean x:Key="/Default/CodeInspection/Roslyn/RoslynEnabled/@EntryValue">False</s:Boolean>

                    <!-- Include/exclude Roslyn analyzers in Solution-Wide Analysis -->
                  	<s:Boolean x:Key="/Default/CodeInspection/Roslyn/UseRoslynInSwea/@EntryValue">False</s:Boolean>

                  </wpf:ResourceDictionary>
            

Use EditorConfig to configure code inspections

If you use EditorConfig to maintain code styles for your project, you can also configure code inspections from .editorconfig files.

As EditorConfig convention suggests, InspectCode will apply inspection settings defined in files named .editorconfig in the directory of the current file and in all its parent directories until it reaches the root filepath or finds an EditorConfig file with root=true. File masks specified in .editorconfig files, for example *Test.cs are also taken into account.

Inspection settings in .editorconfig files are configured similarly to other properties — by adding the corresponding lines:

[inspection_property]=[error | warning | suggestion | hint | none]

For example, you can change the severity level of the Possible 'System.NullReferenceException' inspection to Error with the following line:

resharper_possible_null_reference_exception_highlighting=error

or you can disable the Redundant argument with default value inspection with the following line:

resharper_redundant_argument_default_value_highlighting=none

You can find EditorConfig property for each inspection on pages in the Code inspection index section as well as on the Index of EditorConfig properties page. — just use the browser search to find the property for the desired inspection.

Run analysis locally

Pull the image from Docker Hub (only necessary to update to the latest version):
docker pull jetbrains/qodana-cdnet:2024.1-eap
Run the following command to start inspecting your source code:
docker run \ -v <source-directory>/:/data/project/ \ -v <output-directory>/:/data/results/ \ -e QODANA_TOKEN="<cloud-project-token>" \ jetbrains/qodana-cdnet:2024.1-eap
where source-directory and output-directory are full local paths to, respectively, the project source code directory and the analysis results directory. The QODANA_TOKEN variable refers to the project token required by the linter license. Using the linter without the project token is useless because it does not support showing inspection results locally.

If you don't need the user interface and prefer to review raw data, use the following command:

                        docker run \
                           -v <source-directory>/:/data/project/ \
                           -v <output-directory>/:/data/results/ \
                           -e QODANA_TOKEN="<cloud-project-token>" \
                           jetbrains/qodana-cdnet:2024.1-eap
                    

The output-directory will contain the inspection report.

If you run the analysis several times in a row, make sure you've cleaned the results directory before using it in docker run again.

In the project root directory, run this command to inspect your code and view the inspection report locally:

                        qodana scan \
                           -e QODANA_TOKEN="<cloud-project-token>" \
                           -l jetbrains/qodana-cdnet:2024.1-eap \
                           --show-report
                    

If you don't need the user interface and prefer to review raw data, use the following command:

                        qodana scan \
                           -e QODANA_TOKEN="<cloud-project-token>" \
                           -l jetbrains/qodana-cdnet:2024.1-eap \
                           --results-dir <output-directory>
                    

The output-directory specifies the directory where the SARIF-formatted report will be saved. The QODANA_TOKEN variable refers to the project token required by the license.

Run analysis in CI

Use the following command as a task in a generic shell executor:

                        docker run \
                           -v <source-directory>/:/data/project/ \
                           -v <output-directory>/:/data/results/ \
                           -e QODANA_TOKEN="<cloud-project-token>" \
                           jetbrains/qodana-cdnet:2024.1-eap
                    

where source-directory and output-directory are full paths to, respectively, the project source code directory and the analysis results directory. The QODANA_TOKEN variable refers to the project token required by the Ultimate and Ultimate Plus linters.

Consider using the Quality gate feature to make the build fail when a certain number of problems is reached and the Baseline feature to compare each new linter run to some initial run selected as a baseline.

Run this command in the project root directory:

                        qodana scan \
                           -e QODANA_TOKEN="<cloud-project-token>" \
                           -l jetbrains/qodana-cdnet:2024.1-eap \
                           --results-dir <output-directory>
                    

This will save inspection results to the directory specified by output-directory.

You can also apply the Quality gate feature to make the build fail when a certain number of problems is reached by using the --fail-threshold option.

The Baseline feature compares each new Qodana Community for .NET run to some initial run using the --baseline and --baseline-include-absent options.

Run analysis in GitHub

This feature requires that you specify the Qodana Community for .NET name either in the qodana.yaml file, or using the args configuration option of GitHub, for example:

args: --linter,qodana-cdnet:2024.1-eap

In GitHub, Qodana is implemented as the Qodana Scan GitHub Action.To configure the Qodana Scan GitHub Action, save the .github/workflows/code_quality.yml file containing the workflow configuration:

                    name: Qodana
                    on:
                      workflow_dispatch:
                      pull_request:
                      push:
                        branches:
                          - main
                          - 'releases/*'

                    jobs:
                      qodana:
                        runs-on: ubuntu-latest
                        steps:
                          - uses: actions/checkout@v3
                            with:
                              fetch-depth: 0
                          - name: 'Qodana Scan'
                            uses: JetBrains/qodana-action@v2024.1
                

To authorize in Qodana Cloud and forward reports to it, follow these steps:

In the GitHub UI, create the QODANA_TOKEN encrypted secret and save the project token as its value.
In a GitHub workflow, add this snippet to invoke the Qodana Scan action:
- name: 'Qodana Scan' uses: JetBrains/qodana-action@v2024.1 env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}

Analyze specific solution or project

By default, Qodana tries to locate and employ a single solution file, or, if no solution file is present, it tries to find a project file. If your project contains multiple solution files, you need to specify the exact filename using the --solution option and a relative path to a solution file. For example, to make Qodana always analyze the MySolution.sln solution file, you can use:

--solution=MySolution.sln

Alternatively, you can specify the solution filename in the qodana.yaml file using the solution option and a relative path to a solution file:

            dotnet:
                solution: MySolution.sln
        

If your project contains no solution files and multiple project files, you need to use the --project option and a relative path to a project file. For example, for the MyProject.csproj project file you can use:

--project=MyProject.csproj

Alternatively, you can specify the project filename in the qodana.yaml file using the project option:

            dotnet:
                project: MyProject.csproj
        

Configure a solution

A solution configuration defines which projects in the solution are build, and which project configurations are used for specific projects within the solution.

Each newly-created solution includes the Debug and Release configurations, which can be complemented by your custom configurations.

You can switch configurations of the current solution using the --configuration option. For example, use this to switch to the Release configuration:

--configuration=Release

Alternatively, you can specify the configuration in qodana.yaml:

                dotnet:
                  configuration: Release
            

By default, the solution platform is set to Any CPU .You can override this using the --platform option:

--platform=x86

Alternatively, you can specify the platform in qodana.yaml:

                dotnet:
                  platform: x86
            

Usage statistics

According to the JetBrains EAP user agreement, we can use third-party services to analyze the usage of our features to further improve the user experience. All data will be collected anonymously. You can disable statistics by using the --no-statistics=true CLI option.

Last modified: 29 May 2024