.NET

All Qodana linters are based on JetBrains IDEs designed for particular programming languages and frameworks. To analyze .NET projects, you can use the following Qodana linters:

Characteristic	Description
Linter name	`qodana-dotnet`
Docker image	`jetbrains/qodana-dotnet:2025.2<-privileged>`*
Based on	JetBrains Rider
Available under licenses	Ultimate and Ultimate Plus licenses
Shipped as	A native solution and a Docker image
Supported languages	C#, C/C++, VB.NET, JavaScript, TypeScript, F#

Characteristic	Description
Linter name	`qodana-cdnet`
Docker image	`jetbrains/qodana-cdnet:2025.2-eap<-privileged>`*
Based on	JetBrains ReSharper
Available under licenses	Community license
Shipped as	A Docker image
Supported languages	C#, C/C++, VB.NET

* Using the optional -privileged tag, you can run Qodana in the privileged mode to execute commands that require root access. In this case, Qodana comes with a default qodana user that possesses root privileges and does not require a password.

You can compare these linters by programming languages and other supported technologies by navigating to the feature matrix.

Before you start

Qodana Cloud

To run linters, you need to get a project token that will be used by Qodana for identifying and verifying a license.

Navigate to Qodana Cloud and create an account there.
In Qodana Cloud, create an organization, a team, and a project.
On the project card, you can find the project token that you will be using further in this section.

A project token is required for the Qodana for .NET linter and optional for the Qodana Community for .NET linter.

SDK version

If you project targets the .NET Framework or OS-specific TFMs, the only option in this case is to run the Qodana for .NET linter in native mode.

If you run Qodana for .NET in native mode, you should install the SDK to the default location in your operating system so that Rider can have access to it.

The Dockerized version of Qodana for .NET provides versions 8.0 and 9.0 of SDK.

All SDK versions are stored in the /usr/share/dotnet/sdk directory of the Qodana container filesystem.

In case a project requires a different version of the SDK, you can set it using the bootstrap key in the qodana.yaml file. For example, this command will install the required version of the SDK that is specified in the global.json file and located in the root of your project:

    bootstrap: curl -fsSL https://dot.net/v1/dotnet-install.sh |
      bash -s -- --jsonfile /data/project/global.json -i /usr/share/dotnet

Prepare your software

This shows how to configure software from this section to Qodana analysis. All configuration samples use a project token, see the Qodana Cloud section for details.

On the Settings tab of the GitHub UI, create the QODANA_TOKEN encrypted secret and save the project token as its value.

In Jenkins, make sure that these plugins are up and running:
- Docker and Docker Pipeline are required for running Docker images
- git is required for git operations in Jenkins projects
Make sure that Docker is installed and accessible to Jenkins.
If applicable, make sure that Docker is accessible to the jenkins user as described in the Manage Docker as a non-root user section of the Docker documentation.
In Jenkins, create the qodana-token credential and save the project token as its value.
In Jenkins, create a Multibranch Pipeline project as described on the Jenkins documentation portal.

Make sure that your project repository is accessible to GitLab CI/CD.
In GitLab CI/CD UI create the QODANA_TOKEN environment variable and save the project token as its value.

If you wish to run the Qodana for .NET linter, then in TeamCity create a project and a build configuration.

Install Docker on the machine where you are going to run Qodana.

If you are using Linux, you should be able to run Docker under your current non-root user.

Follow the instructions from the Qodana CLI page on GitHub.

Run this command to pull the Docker image of the Qodana for .NET or Qodana Community for .NET linters:

docker pull qodana-dotnet<-privileged>

docker pull qodana-cdnet<-privileged>

The privileged tag lets you execute commands that need root access because in this case Qodana comes with a default qodana user who possesses root privileges and does not require a password.

Build the project

We recommend that you build a project before Qodana analyzes it. To build it, you can use the bootstrap key of the qodana.yaml file contained in your project directory. This is especially recommended if you employ source generators.

If the project build fails, code analysis cannot be performed.

The Qodana Community for .NET linter builds your project by default before analysis. If you wish to run your custom build, use the --no-build Qodana option:

Use this workflow configuration to invoke the --no-build option:

                    name: Qodana
                    on:
                      workflow_dispatch:
                      pull_request:
                      push:
                        branches: # Specify your branches here
                          - main # The 'main' branch
                          - 'releases/*' # The release branches
                    jobs:
                      qodana:
                        runs-on: ubuntu-latest
                        permissions:
                          contents: write
                          pull-requests: write
                          checks: write
                        steps:
                          - uses: actions/checkout@v3
                            with:
                              ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
                              fetch-depth: 0  # a full history is required for pull request analysis
                          - name: 'Qodana Scan'
                            uses: JetBrains/qodana-action@v2025.2
                            with:
                                args: --no-build
                            env:
                              QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
                

In the root directory of your project repository, save this configuration to the Jenkinsfile:

                    pipeline {
                        environment {
                            QODANA_TOKEN=credentials('qodana-token')
                        }
                        agent {
                            docker {
                                args '''
                                  -v "${WORKSPACE}":/data/project
                                  --entrypoint=""
                                  '''
                                image 'qodana-cdnet<-privileged>'
                            }
                        }
                        stages {
                            stage('Qodana') {
                                steps {
                                    sh '''
                                    qodana \
                                    --no-build
                                    '''
                                }
                            }
                        }
                    }
                

The privileged tag lets you execute commands that need root access because in this case Qodana comes with a default qodana user who possesses root privileges and does not require a password.

                include:
                   - component: $CI_SERVER_FQDN/qodana/qodana/qodana-gitlab-ci@v2025.2
                     inputs:
                        args: --no-build
                

                          qodana scan \
                             -e QODANA_TOKEN="<cloud-project-token>" \
                             jetbrains/qodana-cdnet:2025.2-eap<-privileged> \
                             --no-build
                        

                          docker run \
                             -v <source-directory>/:/data/project/ \
                             -e QODANA_TOKEN="<cloud-project-token>" \
                             jetbrains/qodana-cdnet:2025.2-eap<-privileged> \
                             --no-build
                        

Run Qodana

Basic use case

You can run the Qodana for .NET linter in two modes:

Native mode is the recommended method for running the Qodana for .NET linter that lets you run the linter without using Docker containers
Container mode is an alternative that involves Docker containers of the Qodana for .NET linter

You can configure native mode by using the --linter and --within-docker options:

To analyze the main branch, release branches and the pull requests coming to your repository in native mode, on the Actions tab of the GitHub UI set up a new workflow and save the following workflow configuration to the .github/workflows/code_quality.yml file:

                                name: Qodana
                                on:
                                  workflow_dispatch:
                                  pull_request:
                                  push:
                                    branches: # Specify your branches here
                                      - main # The 'main' branch
                                      - 'releases/*' # The release branches
                                jobs:
                                  qodana:
                                    runs-on: ubuntu-latest
                                    permissions:
                                      contents: write
                                      pull-requests: write
                                      checks: write
                                    steps:
                                      - uses: actions/checkout@v3
                                        with:
                                          ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
                                          fetch-depth: 0  # a full history is required for pull request analysis
                                      - name: 'Qodana Scan'
                                        uses: JetBrains/qodana-action@v2025.2
                                        with:
                                            args: | 
                                                --linter,qodana-dotnet,
                                                --within-docker,false
                                        env:
                                          QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
                            

Run this command in the project root directory:

                        qodana scan \
                           --linter qodana-dotnet \
                           --within-docker false
                    

Container mode is available for the Qodana for .NET linter; however, it is advised that you use native mode.

                                name: Qodana
                                on:
                                  workflow_dispatch:
                                  pull_request:
                                  push:
                                    branches: # Specify your branches here
                                      - main # The 'main' branch
                                      - 'releases/*' # The release branches
                                jobs:
                                  qodana:
                                    runs-on: ubuntu-latest
                                    permissions:
                                      contents: write
                                      pull-requests: write
                                      checks: write
                                    steps:
                                      - uses: actions/checkout@v3
                                        with:
                                          ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
                                          fetch-depth: 0  # a full history is required for pull request analysis
                                      - name: 'Qodana Scan'
                                        uses: JetBrains/qodana-action@v2025.2
                                        env:
                                          QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
                            

In the root directory of your project repository, save the Jenkinsfile containing the following configuration:

                        pipeline {
                            environment {
                                QODANA_TOKEN=credentials('qodana-token')
                            }
                            agent {
                                docker {
                                    args '''
                                      -v "${WORKSPACE}":/data/project
                                      --entrypoint=""
                                      '''
                                    image 'jetbrains/qodana-dotnet:2025.2'
                                }
                            }
                            stages {
                                stage('Qodana') {
                                    steps {
                                        sh '''qodana'''
                                    }
                                }
                            }
                        }
                    

The privileged tag lets you execute commands that need root access because in this case Qodana comes with a default qodana user who possesses root privileges and does not require a password.

In the root directory of your project, create the .gitlab-ci.yml and save the following configuration there:

                        include:
                           - component: $CI_SERVER_FQDN/qodana/qodana/qodana-gitlab-ci@v2025.2
                             inputs:
                                args: --linter,qodana-dotnet
                    

The privileged tag lets you execute commands that need root access because in this case Qodana comes with a default qodana user who possesses root privileges and does not require a password.

In the TeamCity UI, navigate to the configuration page of a build where you would like to run Qodana.
On the Build Configuration Settings page, navigate to the Build steps page.
On the Build steps page, click the Add build step button.
On the page that opens, select the Qodana runner.
On the New Build Step: Qodana page, click Show advanced options and configure the Qodana runner:
- Step name uniquely identifies this step among other build steps.
- Step ID uniquely identifies this step among other build steps.
- Execute step configures the build condition that will trigger this build step.
- Working directory sets the directory for the build process, see the TeamCity documentation for details. You can leave this field empty if the Checkout directory parameter is specified on the Version Control Settings tab.
- Report ID uniquely identifies the report to let you distinguish between multiple reports when several analysis steps are configured within a single build.
- The Forward reports to TeamCity tests checkbox configures Qodana report availability in the Test tab of the TeamCity UI. Using this option, you can view codebase problems along with other problems detected.
- Linter configures the Qodana linter.
  Here, select the Qodana for .NET linter.
- Version is by default set to Latest.
- Inspection profile defines an inspection profile:
  - qodana.starter (default) is one of the default profiles.
  - Profile name lets you specify a profile, see the Existing Qodana profiles section for details.
  - Profile path lets you specify the path to your custom profile. To use this option, make sure that you also configure the custom profile in the qodana.yaml file.
- Cloud Token configures a project token generated in Qodana Cloud.
- Additional Docker arguments configure the arguments accepted by a Docker image, see the Configuration options section for details.
- Additional Qodana arguments let you extend the default Qodana functionality, see the Types of options section for details.
- Qodana CLI version lets you specify the Qodana CLI version that you would like to use.
Click the Save button.

Start local analysis with source-directory pointing to the root of your project and QODANA_TOKEN referring to the project token:

                        docker run \
                           -v <source-directory>/:/data/project/ \
                           -e QODANA_TOKEN="<cloud-project-token>" \
                           jetbrains/qodana-dotnet:2025.2
                    

In Rider, navigate to Tools | Qodana | Try Code Analysis with Qodana.
On the Run Qodana dialog, you can configure:
- Options used by Qodana and configured by the qodana.yaml file
- The Send analysis results to Qodana Cloud option using a project token
- The Use Qodana analysis baseline option to run Qodana with a baseline
Click Run for analyzing your code.
In the Server-Side Analysis tool window, see the analysis results.

You can run the Qodana Community for .NET linter in a container mode as shown in the examples below.

                                name: Qodana
                                on:
                                  workflow_dispatch:
                                  pull_request:
                                  push:
                                    branches: # Specify your branches here
                                      - main # The 'main' branch
                                      - 'releases/*' # The release branches
                                jobs:
                                  qodana:
                                    runs-on: ubuntu-latest
                                    permissions:
                                      contents: write
                                      pull-requests: write
                                      checks: write
                                    steps:
                                      - uses: actions/checkout@v3
                                        with:
                                          ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
                                          fetch-depth: 0  # a full history is required for pull request analysis
                                      - name: 'Qodana Scan'
                                        uses: JetBrains/qodana-action@v2025.2
                                        env:
                                          QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
                            

In the root directory of your project repository, save this snippet to the Jenkinsfile:

                        pipeline {
                            environment {
                                QODANA_TOKEN=credentials('qodana-token')
                            }
                            agent {
                                docker {
                                    args '''
                                      -v "${WORKSPACE}":/data/project
                                      --entrypoint=""
                                      '''
                                    image 'jetbrains/qodana-cdnet:2025.2-eap'
                                }
                            }
                            stages {
                                stage('Qodana') {
                                    steps {
                                        sh '''qodana'''
                                    }
                                }
                            }
                        }
                    

The privileged tag lets you execute commands that need root access because in this case Qodana comes with a default qodana user who possesses root privileges and does not require a password.

In the root directory of your project, create the .gitlab-ci.yml and save the following configuration there:

                        include:
                           - component: $CI_SERVER_FQDN/qodana/qodana/qodana-gitlab-ci@v2025.2
                             inputs:
                                args: --linter,qodana-cdnet
                    

Start local analysis with source-directory pointing to the root of your project and QODANA_TOKEN referring to the project token:

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

In Rider, navigate to Tools | Qodana | Try Code Analysis with Qodana.
On the Run Qodana dialog, you can configure:
- Options used by Qodana and configured by the qodana.yaml file.
- The Send analysis results to Qodana Cloud option using a project token.
- The Use Qodana analysis baseline option to run Qodana with a baseline.
Click Run for analyzing your code.
In the Server-Side Analysis tool window, see the analysis results.

Analyze a specific solution

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 as shown below.

You can specify a solution in various ways. Using a YAML configuration is the most convenient method because you can configure it once and use the configuration across all software that runs Qodana. Alternatively, you can use Docker options.

Specify the relative path to the solution file from the project root:

                    dotnet:
                      solution: <relative-path-to-solution-file>
                

If your project contains no solution files and multiple project files, you need to employ a project file:

                    dotnet:
                      project: <relative-path-to-project-file>
                

The Qodana for .NET linter uses the --property option, while the Qodana Community for .NET linter uses the --solution and --project options to specify a path to a solution file:

                      docker run \
                         -v <source-directory>/:/data/project/ \
                         -e QODANA_TOKEN="<cloud-project-token>" \
                         jetbrains/qodana-dotnet:2025.2<-privileged> \
                         --property=qodana.net.solution=<relative-path-to-solution-file>
                    

                      docker run \
                         -v <source-directory>/:/data/project/ \
                         -e QODANA_TOKEN="<cloud-project-token>" \
                         jetbrains/qodana-cdnet:2025.2-eap<-privileged> \
                         --solution=<relative-path-to-solution-file>
                    

If your project contains no solution files and multiple project files, you need to employ a project file using the --property and --project options:

                            docker run \
                               -v <source-directory>/:/data/project/ \
                               -e QODANA_TOKEN="<cloud-project-token>" \
                               jetbrains/qodana-dotnet:2025.2<-privileged> \
                               --property=qodana.net.project=<relative-path-to-project-file>
                        

                            docker run \
                               -v <source-directory>/:/data/project/ \
                               -e QODANA_TOKEN="<cloud-project-token>" \
                               jetbrains/qodana-cdnet:2025.2-eap<-privileged> \
                               --project=<relative-path-to-project-file>
                        

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

Every solution contains the Debug and Release configurations that you can employ as shown below.

You can switch configurations of the current solution in the qodana.yaml file:

                    dotnet:
                      configuration: Release
                

By default, the solution platform is set to Any CPU, and you can override it, for example:

                    dotnet:
                      platform: x86
                

You can apply a configuration using the --property and --configuration options:

                            docker run \
                               -v <source-directory>/:/data/project/ \
                               -e QODANA_TOKEN="<cloud-project-token>" \
                               jetbrains/qodana-dotnet:2025.2<-privileged> \
                               --property=qodana.net.configuration=Release
                        

                            docker run \
                               -v <source-directory>/:/data/project/ \
                               -e QODANA_TOKEN="<cloud-project-token>" \
                               jetbrains/qodana-cdnet:2025.2-eap<-privileged> \
                               --configuration=Release
                        

By default, the solution platform is set to Any CPU, and you can override it as shown below:

                            docker run \
                               -v <source-directory>/:/data/project/ \
                               -e QODANA_TOKEN="<cloud-project-token>" \
                               jetbrains/qodana-dotnet:2025.2<-privileged> \
                               --property=qodana.net.platform=x86
                        

                            docker run \
                               -v <source-directory>/:/data/project/ \
                               -e QODANA_TOKEN="<cloud-project-token>" \
                               jetbrains/qodana-cdnet:2025.2-eap<-privileged> \
                               --platform=x86
                        

Private NuGet repositories

Depending on the linter, you can run Qodana using private NuGet repositories as shown below.

If you run Qodana for .NET using private NuGet repositories, native mode of this linter is the recommended method of running. In this case, dependencies are basically restored in steps that precede Qodana execution, for example:

                name: Qodana
                on:
                  workflow_dispatch:
                  pull_request:
                  push:
                 
                jobs:
                    qodana:
                        runs-on: ubuntu-latest
                        permissions:
                            contents: write
                            pull-requests: write
                            checks: write
                        steps:
                            - uses: actions/checkout@v3
                              with:
                                ref: ${{ github.event.pull_request.head.sha }}
                                fetch-depth: 0
                            - name: Setup .NET
                              uses: actions/setup-dotnet@v4
                              with:
                                  dotnet-version: '8.x' # or your version
                             
                            - name: Add NuGet source
                              run: |
                                dotnet nuget add source ${{ secrets.QODANA_NUGET_URL }} \
                                  --name MyPrivateFeed \
                                  --username ${{ secrets.QODANA_NUGET_USER }} \
                                  --password ${{ secrets.QODANA_NUGET_PASSWORD }} \
                                  --store-password-in-clear-text
                             
                            - name: Restore dependencies
                              run: dotnet restore
                             
                             - name: 'Qodana Scan'
                              uses: JetBrains/qodana-action@main
                              env:
                                QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
                              with:
                                upload-result: true
                

In the container mode, save the following configuration to the qodana.yaml file:

                    bootstrap: |
                      dotnet new nugetconfig --force
                      dotnet nuget add source -u $QODANA_NUGET_USER -p $QODANA_NUGET_PASSWORD --store-password-in-clear-text -n PrivateFeed $QODANA_NUGET_URL --configfile nuget.config
                    # If you already have nuget.config in your repository, you can use instead:
                    # dotnet nuget update source &ltfeed-name> -u $QODANA_NUGET_USER -p $QODANA_NUGET_PASSWORD --store-password-in-clear-text --configfile nuget.config
                

Here is the example configuration showing how you can run Qodana in the container mode:

                name: Qodana
                    on:
                      workflow_dispatch:
                      pull_request:
                      push:
                     
                    jobs:
                      qodana:
                        runs-on: ubuntu-latest
                        permissions:
                          contents: write
                          pull-requests: write
                          checks: write
                        steps:
                          - uses: actions/checkout@v3
                            with:
                              ref: ${{ github.event.pull_request.head.sha }}
                              fetch-depth: 0
                           
                          - name: 'Qodana Scan'
                            uses: JetBrains/qodana-action@main
                            env:
                              QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
                              QODANA_NUGET_URL: ${{ secrets.QODANA_NUGET_URL }}
                              QODANA_NUGET_USER: ${{ secrets.QODANA_NUGET_USER }}
                              QODANA_NUGET_PASSWORD: ${{ secrets.QODANA_NUGET_PASSWORD }}
                            with:
                              upload-result: true
                

Add credentials to the nuget.config file before analyzing a project. You can do this by executing a NuGet source update using:

            -Name "MySourceName” -username "User" -password "Password" -configFile "pathToNugetConfigInRepo"
        

Explore analysis results

You can load the latest Qodana report from Qodana Cloud to your IDE as explained below.

In your IDE, navigate to Tools | Qodana | Log in to Qodana.
On the Settings dialog, click Log in.
This will redirect you to the authentication page.
Select the Qodana Cloud project to link your local project with.
If you check the Always load most relevant Qodana report option, you will be able to receive the most actual and relevant reports from Qodana Cloud.
In this case, the IDE will search and fetch from Qodana Cloud the report with the revision ID corresponding to the current revision ID (HEAD). If this report was not found, the IDE will select the previous report with the revision closest to the current revision ID (HEAD). Otherwise, the IDE retrieves the latest available report from Qodana Cloud.
On the Server-Side Analysis tab of the Problems tool window, you can view the analysis results.

Once Qodana analyzed your project and uploaded the analysis results to Qodana Cloud, navigate to your project in Qodana Cloud and review the analysis results report.

To learn more about Qodana report UI, see the Analysis reports section.

Extend the configuration

Adjusting the scope of analysis

Out of the box, Qodana provides two predefined profiles hosted on GitHub. The qodana.starter profile is the default profile and a subset of the more comprehensive qodana.recommended profile that in turn is suitable for running in CI/CD pipelines and mostly implements the default Rider profile.

Qodana for .NET reads configuration from the qodana.yaml file located in the root directory of your project. For example, add this configuration to run the linter using the qodana.recommended inspection profile:

                version: "1.0"
                profile:
                    name: qodana.recommended
            

You can analyze your code using Roslyn analyzers with each analyzer considered as a separate inspection. This is an experimental feature, so use them at your own risk.

To disable Roslyn analyzers, you can configure the Qodana profile using the qodana.yaml file, for example:

                name: "Custom profile"
                 
                baseProfile: qodana.starter
                 
                groups: # List of configured groups
                - groupId: InspectionsToExclude
                  groups:
                    - "category:C#/Roslyn Analyzers"
                 
                inspections: # Group invocation
                - group: InspectionsToExclude
                  enabled: false # Disable the InspectionsToExclude group
            

Configuration examples are available on GitHub.

If you are familiar with configuring code analysis via Rider inspection profiles, you can pass the reference to the existing profile by mapping the profile:

                docker run \
                   -v $(pwd):/data/project/ \
                   -v $(pwd)/.qodana/<inspection-profile.xml>:/data/project/myprofiles/<inspection-profile.xml> \
                   -e QODANA_TOKEN="<cloud-project-token>" \
                   jetbrains/qodana-dotnet:2025.2<-privileged> \
                   --profile-path /data/project/myprofiles/<inspection-profile.xml>
            

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. To disable Roslyn analyzers, in the solution .DotSettings file add the following configuration:

                <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>
            

Using EditorConfig

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.

Enabling the baseline feature

You can skip analysis for specific problems by using the baseline feature. Information about a baseline is contained in a SARIF-formatted file.

Select how you would like to run the Qodana for .NET linter with the baseline feature:

You can run the Qodana for .NET linter in the native mode:

Save this snippet to the .github/workflows/code_quality.yml file:

                              name: Qodana
                              on:
                                workflow_dispatch:
                                pull_request:
                                push:
                                  branches: # Specify your branches here
                                    - main # The 'main' branch
                                    - master # The 'master' branch
                                    - 'releases/*' # The release branches
                              jobs:
                                qodana:
                                  runs-on: ubuntu-latest
                                  permissions:
                                    contents: write
                                    pull-requests: write
                                    checks: write
                                  steps:
                                    - uses: actions/checkout@v3
                                      with:
                                        ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
                                        fetch-depth: 0  # a full history is required for pull request analysis
                                    - name: 'Qodana Scan'
                                      uses: JetBrains/qodana-action@v2025.2
                                      with: 
                                        args: |
                                            --linter,qodana-dotnet,
                                            --within-docker,false,
                                            --baseline,<path/to/qodana.sarif.json>
                                      env:
                                        QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
                          

This snippet has the args: --baseline,<path/to/qodana.sarif.json> line that specifies the path to the SARIF file containing a baseline.

Run this command in the project root directory:

                                qodana scan \
                                   --linter qodana-dotnet \
                                   --within-docker false \
                                   --baseline <path/to/qodana.sarif.json>
                            

Here, the --baseline <path/to/qodana.sarif.json> option specifies the baseline feature.

In your browser, open Qodana Cloud to examine the analysis results and reconfigure the analysis. See the Analysis reports section of the documentation for full details.

Select how you would like to run the baseline feature in the container mode:

Save this snippet to the .github/workflows/code_quality.yml file:

                              name: Qodana
                              on:
                                workflow_dispatch:
                                pull_request:
                                push:
                                  branches: # Specify your branches here
                                    - main # The 'main' branch
                                    - master # The 'master' branch
                                    - 'releases/*' # The release branches
                              jobs:
                                qodana:
                                  runs-on: ubuntu-latest
                                  permissions:
                                    contents: write
                                    pull-requests: write
                                    checks: write
                                  steps:
                                    - uses: actions/checkout@v3
                                      with:
                                        ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
                                        fetch-depth: 0  # a full history is required for pull request analysis
                                    - name: 'Qodana Scan'
                                      uses: JetBrains/qodana-action@v2025.2
                                      with:
                                        args: | 
                                            --baseline,<path/to/qodana.sarif.json>,
                                            --linter,qodana-dotnet
                                      env:
                                        QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
                          

This snippet has the args: --baseline,<path/to/qodana.sarif.json> line that specifies the path to the SARIF file containing a baseline.

In the root directory of your project repository, save the Jenkinsfile containing the --baseline <path/to/qodana.sarif.json> line that specifies the path to the SARIF-formatted baseline file:

                            pipeline {
                                environment {
                                    QODANA_TOKEN=credentials('qodana-token')
                                }
                                agent {
                                    docker {
                                        args '''
                                          -v "${WORKSPACE}":/data/project
                                          --entrypoint=""
                                          '''
                                        image 'jetbrains/qodana-dotnet:2025.2'
                                    }
                                }
                                stages {
                                    stage('Qodana') {
                                        steps {
                                            sh '''
                                            qodana \
                                            --baseline <path/to/qodana.sarif.json>
                                            '''
                                        }
                                    }
                                }
                            }
                          

In the root directory of your project, save this snippet to the .gitlab-ci.yml file:

                            include:
                               - component: $CI_SERVER_FQDN/qodana/qodana/qodana-gitlab-ci@v2025.2
                                 inputs:
                                    args: | 
                                        --baseline,<path/to/qodana.sarif.json>,
                                        --linter,qodana-dotnet
                          

The --baseline <path/to/qodana.sarif.json> line in the script block invokes the baseline feature.

In the TeamCity UI, navigate to the configuration page of a build where you would like to run Qodana.
On the Build Configuration Settings page, navigate to the Build steps page.
On the Build steps page, click the Add build step button.
On the page that opens, select the Qodana runner.
On the New Build Step: Qodana page, click Show advanced options and configure the Qodana runner:
- Step name uniquely identifies this step among other build steps.
- Step ID uniquely identifies this step among other build steps.
- Execute step configures the build condition that will trigger this build step.
- Working directory sets the directory for the build process, see the TeamCity documentation for details. You can leave this field empty if the Checkout directory parameter is specified on the Version Control Settings tab.
- Report ID uniquely identifies the report to let you distinguish between multiple reports when several analysis steps are configured within a single build.
- The Forward reports to TeamCity tests checkbox configures Qodana report availability in the Test tab of the TeamCity UI. Using this option, you can view codebase problems along with other problems detected.
- Linter configures the Qodana linter.
  Here, select the Qodana for .NET linter.
- Version is by default set to Latest.
- Inspection profile defines an inspection profile:
  - qodana.starter (default) is one of the default profiles.
  - Profile name lets you specify a profile, see the Existing Qodana profiles section for details.
  - Profile path lets you specify the path to your custom profile. To use this option, make sure that you also configure the custom profile in the qodana.yaml file.
- Cloud Token configures a project token generated in Qodana Cloud.
- Additional Docker arguments configure the arguments accepted by a Docker image, see the Configuration options section for details.
- Additional Qodana arguments let you extend the default Qodana functionality, see the Types of options section for details.
  In this field, specify the baseline feature using the --baseline <path/to/qodana.sarif.json> option.
- Qodana CLI version lets you specify the Qodana CLI version that you would like to use.
Click the Save button.

Choose how you would like to run the baseline feature from the command line:

                                      qodana scan \
                                         -v <path_to_baseline>:/data/base/ \
                                         -e QODANA_TOKEN="<cloud-project-token>" \
                                         --linter qodana-dotnet \
                                         --baseline /data/base/<path-relative-to-project-dir>/qodana.sarif.json
                                  

                                      docker run \
                                         -v <source-directory>/:/data/project/ \
                                         -v <path_to_baseline>:/data/base/ \
                                         -e QODANA_TOKEN="<cloud-project-token>" \
                                         jetbrains/qodana-dotnet:2025.2 \
                                         --baseline /data/base/<path-relative-to-project-dir>/qodana.sarif.json
                                  

In your IDE, navigate to the Problems tool window.
In the Problems tool window, click the Server-Side Analysis tab.
On the Server-Side Analysis tab, click the Try Locally button.
On the dialog that opens, expand the Advanced configuration section and specify the path to the baseline file, and then click Run.

Select how you would like to run the Qodana Community for .NET linter with the baseline feature:

Save this snippet to the .github/workflows/code_quality.yml file:

                      name: Qodana
                      on:
                        workflow_dispatch:
                        pull_request:
                        push:
                          branches: # Specify your branches here
                            - main # The 'main' branch
                            - master # The 'master' branch
                            - 'releases/*' # The release branches
                      jobs:
                        qodana:
                          runs-on: ubuntu-latest
                          permissions:
                            contents: write
                            pull-requests: write
                            checks: write
                          steps:
                            - uses: actions/checkout@v3
                              with:
                                ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
                                fetch-depth: 0  # a full history is required for pull request analysis
                            - name: 'Qodana Scan'
                              uses: JetBrains/qodana-action@v2025.2
                              with:
                                args: |
                                    --linter,qodana-cdnet,
                                    --baseline,<path/to/qodana.sarif.json>
                              env:
                                QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
                  

This snippet has the args: --baseline,<path/to/qodana.sarif.json> line that specifies the path to the SARIF file containing a baseline.

In the root directory of your project repository, save the Jenkinsfile containing the --baseline <path/to/qodana.sarif.json> line that specifies the path to the SARIF-formatted baseline file:

                    pipeline {
                        environment {
                            QODANA_TOKEN=credentials('qodana-token')
                        }
                        agent {
                            docker {
                                args '''
                                  -v "${WORKSPACE}":/data/project
                                  --entrypoint=""
                                  '''
                                image 'jetbrains/qodana-cdnet:2025.2-eap'
                            }
                        }
                        stages {
                            stage('Qodana') {
                                steps {
                                    sh '''
                                    qodana \
                                    --baseline <path/to/qodana.sarif.json>
                                    '''
                                }
                            }
                        }
                    }
                  

In the root directory of your project, save this snippet to the .gitlab-ci.yml file:

                            include:
                               - component: $CI_SERVER_FQDN/qodana/qodana/qodana-gitlab-ci@v2025.2
                                 inputs:
                                    args: |
                                        --baseline,<path/to/qodana.sarif.json>,
                                        --linter,qodana-cdnet
                        

The --baseline <path/to/qodana.sarif.json> line in the script block invokes the baseline feature.

Choose how you would like to run the baseline feature from the command line:

                              qodana scan \
                                 -v <path_to_baseline>:/data/base/ \
                                 -e QODANA_TOKEN="<cloud-project-token>" \
                                 --linter qodana-cdnet \
                                 --baseline /data/base/<path-relative-to-project-dir>/qodana.sarif.json
                          

                              docker run \
                                 -v <source-directory>/:/data/project/ \
                                 -v <path_to_baseline>:/data/base/ \
                                 -e QODANA_TOKEN="<cloud-project-token>" \
                                 jetbrains/qodana-cdnet:2025.2-eap \
                                 --baseline /data/base/<path-relative-to-project-dir>/qodana.sarif.json
                          

Enabling the quality gate

You can configure quality gates for the total number of project problems, specific problem severities, and code coverage by saving this snippet to the qodana.yaml file:

            failureConditions:
              severityThresholds:
                any: 50 # Total number of problems in all severities
                critical: 1 # Severities
                high: 2
                moderate: 3
                low: 4
                info: 5
              testCoverageThresholds:
                fresh: 6 # Fresh code coverage
                total: 7 # Total percentage
        

You can configure quality gates for the total number of project problems by saving this snippet to the qodana.yaml file:

            failureConditions:
              severityThresholds:
                any: 50 # Total number of problems in all severities
        

Analyzing pull requests

You can analyze pull requests using the Qodana for .NET linter.

The Qodana Scan GitHub action automatically analyzes all pull requests, so you do not have to provide any additional configuration. Save this configuration to the .github/workflows/code_quality.yml file:

                name: Qodana
                on:
                  workflow_dispatch:
                  pull_request:
                  push:
                    branches: # Specify your branches here
                      - main # The 'main' branch
                      - 'releases/*' # The release branches
                jobs:
                  qodana:
                    runs-on: ubuntu-latest
                    permissions:
                      contents: write
                      pull-requests: write
                      checks: write
                    steps:
                      - uses: actions/checkout@v3
                        with:
                          ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
                          fetch-depth: 0  # a full history is required for pull request analysis
                      - name: 'Qodana Scan'
                        uses: JetBrains/qodana-action@v2025.2
                        with:
                          args: --linter,qodana-dotnet
                        env:
                          QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
        

In the root directory of your project, save the .gitlab-ci.yml file containing the following snippet:

            include:
               - component: $CI_SERVER_FQDN/qodana/qodana/qodana-gitlab-ci@v2025.2
                 inputs:
                   args: --linter,qodana-dotnet
        

This configuration enables merge request analysis.

Information about configuring TeamCity for analyzing pull and merge requests is available on the TeamCity documentation portal.

To analyze changes in your code, employ the --diff-start option and specify a hash of the commit that will act as a base for comparison:

                    qodana scan \
                       -e QODANA_TOKEN="<cloud-project-token>" \
                       --linter qodana-dotnet \
                       --diff-start=<GIT_START_HASH>
                

                  docker run \
                     -v $(pwd):/data/project/ \
                     -e QODANA_TOKEN="<cloud-project-token>" \
                     jetbrains/qodana-dotnet:2025.2 \
                     --diff-start=<GIT_START_HASH>
                

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, for example:

docker run \
   -v <source-directory>/:/data/project/ \
   -e QODANA_TOKEN="<cloud-project-token>" \
   jetbrains/qodana-dotnet:2025.2&lt;-privileged&gt; \
   --no-statistics=true

Supported technologies and features

Support for	Name	Qodana for .NET	Qodana Community for .NET
Programming languages	C# C++ * VB.NET ** C * JavaScript TypeScript F#	✔ ✔ ✔ ✔ ✔ ✔ ✔	✔ ✔ ✔
Frameworks and libraries	Angular ASPX Blazor ASP.NET Godot Handlebars/Mustache HTTP client Less Node.js NUnit PostCSS Pug/Jade React Roslyn Sass/SCSS Unity Unreal Engine Vue xUnit .NET Core	✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔	✔ ✔ ✔
Databases and ORM	MongoDB MySQL Oracle PostgreSQL SQL SQL server	✔ ✔ ✔ ✔ ✔ ✔
Markup languages and file formats	HTML Razor RegExp ResX XML XAML CSS Docker GitHub Actions JSON and JSON5 JSONPath Kubernetes Markdown OpenAPI RELAX NG ShaderLab T4 XPath XSLT YAML	✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔	✔ ✔ ✔ ✔ ✔ ✔
Scripting languages	Shell script	✔
Build management	MSBuild	✔
Qodana features	Baseline Quality gate Code coverage Insights* License audit* Quick-Fix Single Sign-on***	✔ ✔ ✔ ✔ ✔ ✔ ✔	✔ ✔

* C and C++ inspections are applicable for projects containing .sln files.

** Supports Visual Basic inspections only.

*** Available only under the Ultimate Plus license.

08 October 2025