Qodana 2024.2 Help

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

Linter name

Based on

Licensed under the licenses

Shipped as

Supported languages

Qodana for .NET

JetBrains Rider

Ultimate and Ultimate Plus

A native solution and a Docker image

C#, C/C++, VB.NET, JavaScript, TypeScript

Qodana Community for .NET

JetBrains ReSharper

Community

A Docker image

C#, C++, VB.NET

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

Before your start

Qodana Cloud

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

  1. Navigate to Qodana Cloud and create an account there.

  2. In Qodana Cloud, create an organization, a team, and a project.

  3. 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 the native mode.

If you run Qodana for .NET in the 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 6.0, 7.0, and 8.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 for details.

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

  2. 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: - main 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@v2024.2 with: # args: --linter,jetbrains/qodana-dotnet:2024.2 # args: --linter,jetbrains/qodana-cdnet:2024.2-eap env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}

    This configuration sample will be modified throughout the section.

  1. 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 by Jenkins.

    If applicable, make sure that Docker is accessible by the jenkins user as described in the Manage Docker as a non-root user section of the Docker documentation.

  2. In Jenkins, create the qodana-token credential and save the project token as its value.

  3. In Jenkins, create a Multibranch Pipeline project as described on the Jenkins documentation portal.

  1. Make sure that your project repository is accessible by GitLab CI/CD.

  2. In GitLab CI/CD, create the $qodana_token variable and save the project token as its value.

In TeamCity, Create a project and a build configuration.

Install Docker on the machine were 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 jetbrains/qodana-dotnet:2024.2
docker pull jetbrains/qodana-cdnet:2024.2-eap

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@v2024.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 'jetbrains/qodana-cdnet:2024.2-eap' } } stages { stage('Qodana') { steps { sh ''' qodana \ --no-build ''' } } } }
qodana: image: name: jetbrains/qodana-cdnet:2024.2-eap entrypoint: [""] cache: - key: qodana-2024.2-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG fallback_keys: - qodana-2024.2-$CI_DEFAULT_BRANCH- - qodana-2024.2- paths: - .qodana/cache variables: QODANA_TOKEN: $qodana_token - script: - qodana --cache-dir=$CI_PROJECT_DIR/.qodana/cache --no-build artifacts: paths: - qodana/report/ expose_as: 'Qodana report'

  1. In the TeamCity UI, navigate to the configuration page of a build where you would like to run Qodana.

  2. On the Build Configuration Settings page, navigate to the Build steps page.

  3. On the Build steps page, click the Add build step button.

  4. On the page that opens, select the Qodana runner.

  5. 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 inspection 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, specify either the Qodana for .NET or Qodana Community for .NET linter.

      Here, specify the Qodana Community for .NET linter.

    • Version is by default set to Latest.

    • Inspection profile defines an inspection profile:

      • Recommended (default) is one of the default profiles.

      • Embedded profile lets you select a default profile, see the Existing Qodana profiles section for details.

      • Path to the IntelliJ profile 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 configures the arguments accepted by a Docker image, see the Shell commands section for details.

    • Additional Qodana arguments lets you extend the default Qodana functionality, see the Options section for details.

      In this field, specify the --no-build option.

    Configuring the Qodana runner

  6. Click the Save button.

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

Run Qodana

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

  • The native mode is the recommended method for running the Qodana for .NET linter that lets you run the linter without using Docker containers,

  • The container mode is an alternative that involves Docker containers of the Qodana for .NET linter.

Using a YAML configuration is the preferred method of configuring the linter because it lets you use such configuration across all software that runs Qodana without additional configuration.

You can configure the native mode by adding this line to the qodana.yaml file:

ide: QDNET

Alternatively, you can implement the native mode configuration as shown in examples below.

To inspect the main branch, release branches and the pull requests coming to your repository in the native mode, save this 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@v2024.2 with: args: --ide,QDNET env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}

This configuration invokes the native mode using:

with:    args: --ide,QDNET

Run this command in the project root directory:

qodana scan \    --ide QDNET

Here, the --ide option downloads and employs the JetBrains IDE binary file.

Alternatively, in the qodana.yaml file save ide: QDNET, and then run Qodana using the following command:

qodana scan

  1. In Rider, navigate to Tools | Qodana | Try Code Analysis with Qodana.

  2. On the Run Qodana dialog, you can configure:

    Configuring Qodana in the Run Qodana dialog

    Click Run for analyzing your code.

  3. In the Server-Side Analysis tool window, see the inspection results.

The container mode is available for the Qodana for .NET linter; however, we recommend that you use the native mode.

To analyze the main branch, release branches and the pull requests coming to your repository in the container mode, save this 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@v2024.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:2024.2' } } stages { stage('Qodana') { steps { sh '''qodana''' } } } }

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

qodana: image: name: jetbrains/qodana-dotnet:2024.2 entrypoint: [""] cache: - key: qodana-2024.2-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG fallback_keys: - qodana-2024.2-$CI_DEFAULT_BRANCH- - qodana-2024.2- paths: - .qodana/cache variables: QODANA_TOKEN: $qodana_token - script: - qodana --cache-dir=$CI_PROJECT_DIR/.qodana/cache artifacts: paths: - qodana/report/ expose_as: 'Qodana report'

  1. In the TeamCity UI, navigate to the configuration page of a build where you would like to run Qodana.

  2. On the Build Configuration Settings page, navigate to the Build steps page.

  3. On the Build steps page, click the Add build step button.

  4. On the page that opens, select the Qodana runner.

  5. 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 inspection 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, specify either the Qodana for .NET or Qodana Community for .NET linter.

    • Version is by default set to Latest.

    • Inspection profile defines an inspection profile:

      • Recommended (default) is one of the default profiles.

      • Embedded profile lets you select a default profile, see the Existing Qodana profiles section for details.

      • Path to the IntelliJ profile 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 configures the arguments accepted by a Docker image, see the Shell commands section for details.

    • Additional Qodana arguments lets you extend the default Qodana functionality, see the Options section for details.

    Configuring the Qodana runner

  6. 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:2024.2

  1. In Rider, navigate to Tools | Qodana | Try Code Analysis with Qodana.

  2. On the Run Qodana dialog, you can configure:

    Configuring Qodana in the Run Qodana dialog

    Click Run for analyzing your code.

  3. In the Server-Side Analysis tool window, see the inspection results.

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

To analyze the main branch, release branches and the pull requests coming to your repository in the container mode, save this 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@v2024.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:2024.2-eap' } } stages { stage('Qodana') { steps { sh '''qodana''' } } } }

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

qodana: image: name: jetbrains/qodana-cdnet:2024.2-eap entrypoint: [""] cache: - key: qodana-2024.2-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG fallback_keys: - qodana-2024.2-$CI_DEFAULT_BRANCH- - qodana-2024.2- paths: - .qodana/cache variables: QODANA_TOKEN: $qodana_token - script: - qodana --cache-dir=$CI_PROJECT_DIR/.qodana/cache artifacts: paths: - qodana/report/ expose_as: 'Qodana report'

  1. In the TeamCity UI, navigate to the configuration page of a build where you would like to run Qodana.

  2. On the Build Configuration Settings page, navigate to the Build steps page.

  3. On the Build steps page, click the Add build step button.

  4. On the page that opens, select the Qodana runner.

  5. 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 inspection 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, specify either the Qodana for .NET or Qodana Community for .NET linter.

    • Version is by default set to Latest.

    • Inspection profile defines an inspection profile:

      • Recommended (default) is one of the default profiles.

      • Embedded profile lets you select a default profile, see the Existing Qodana profiles section for details.

      • Path to the IntelliJ profile 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 configures the arguments accepted by a Docker image, see the Shell commands section for details.

    • Additional Qodana arguments lets you extend the default Qodana functionality, see the Options section for details.

    Configuring the Qodana runner

  6. 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-cdnet:2024.2-eap

  1. In Rider, navigate to Tools | Qodana | Try Code Analysis with Qodana.

  2. On the Run Qodana dialog, you can configure:

    Configuring Qodana in the Run Qodana dialog

    Click Run for analyzing your code.

  3. In the Server-Side Analysis tool window, see the inspection 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:2024.2 \    --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:2024.2-eap \    --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:2024.2 \    --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:2024.2-eap \    --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:2024.2 \    --property=qodana.net.configuration=Release
docker run \    -v <source-directory>/:/data/project/ \    -e QODANA_TOKEN="<cloud-project-token>" \    jetbrains/qodana-cdnet:2024.2-eap \    --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:2024.2 \    --property=qodana.net.platform=x86
docker run \    -v <source-directory>/:/data/project/ \    -e QODANA_TOKEN="<cloud-project-token>" \    jetbrains/qodana-cdnet:2024.2-eap \    --platform=x86

Private NuGet repositories

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

If you run Qodana for .NET using private NuGet repositories, the native mode of this linter is the recommended method of running. In this case, you do not have to additionally configure the linter, and if you run it on the same machine where you have built the project, it will be able to have access to the same feeds.

Alternatively, use this configuration to employ a Docker image of the Qodana for .NET linter:

docker run \    -v <source-directory>/:/data/project/ \    -e QODANA_TOKEN="<cloud-project-token>" \    -e QODANA_NUGET_URL=<private-NuGet-feed-URL> \    -e QODANA_NUGET_USER=<login> \    -e QODANA_NUGET_PASSWORD=<plaintext-password> \    jetbrains/qodana-dotnet:2024.2 \

Another method is to 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"

Other configuration examples are available on our GitHub repository.

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.

  1. In your IDE, navigate to Tools | Qodana | Log in to Qodana.

  2. On the Settings dialog, click Log in.

    Connecting to Qodana Cloud

    This will redirect you to the authentication page.

  3. Select the Qodana Cloud project to link your local project with.

    Linking the project to Qodana Cloud

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

    Enabling to load the most relevant reports

    In this case, the IDE will search and fetch from Qodana Cloud the report that has 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.

  5. On the Server-Side Analysis tab of the Problems tool window, view analysis results.

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

Analysis report example

To learn more about Qodana report UI, see the Inspection report 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:2024.2 \    --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:

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

You can skip analysis for specific problems 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@v2024.2 with: args: --ide,QDNET,--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 \    --ide QDNET \    --baseline <path/to/qodana.sarif.json>

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

Alternatively, in the qodana.yaml file save ide: <QDNET>, and then run Qodana using the following command:

qodana scan \    --baseline <path/to/qodana.sarif.json>

In your browser, open Qodana Cloud to examine analysis results and reconfigure the analysis, see the Inspection report section for 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@v2024.2 with: args: --baseline,<path/to/qodana.sarif.json>,--linter,jetbrains/qodana-dotnet:2024.2 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:2024.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:

qodana: image: name: jetbrains/qodana-dotnet:2024.2 entrypoint: [""] cache: - key: qodana-2024.2-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG fallback_keys: - qodana-2024.2-$CI_DEFAULT_BRANCH- - qodana-2024.2- paths: - .qodana/cache variables: QODANA_TOKEN: $qodana_token - script: - qodana --baseline <path/to/qodana.sarif.json> --results-dir=$CI_PROJECT_DIR/.qodana/results --cache-dir=$CI_PROJECT_DIR/.qodana/cache

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

  1. In the TeamCity UI, navigate to the configuration page of a build where you would like to run Qodana.

  2. On the Build Configuration Settings page, navigate to the Build steps page.

  3. On the Build steps page, click the Add build step button.

  4. On the page that opens, select the Qodana runner.

  5. 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 inspection 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, specify either the Qodana for .NET or Qodana Community for .NET linter.

    • Version is by default set to Latest.

    • Inspection profile defines an inspection profile:

      • Recommended (default) is one of the default profiles.

      • Embedded profile lets you select a default profile, see the Existing Qodana profiles section for details.

      • Path to the IntelliJ profile 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 configures the arguments accepted by a Docker image, see the Shell commands section for details.

    • Additional Qodana arguments lets you extend the default Qodana functionality, see the Options section for details.

      In this field, specify the baseline feature using the --baseline <path/to/qodana.sarif.json> option.

    Configuring the Qodana runner

  6. 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>" \ -l jetbrains/qodana-dotnet:2024.2 \ --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:2024.2 \ --baseline /data/base/<path-relative-to-project-dir>/qodana.sarif.json

  1. In your IDE, navigate to the Problems tool window.

  2. In the Problems tool window, click the Server-Side Analysis tab.

  3. On the Server-Side Analysis tab, click the Try Locally button.

  4. 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@v2024.2 with: args: --baseline,<path/to/qodana.sarif.json>,--linter,jetbrains/qodana-cdnet:2024.2-eap 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:2024.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:

qodana: image: name: jetbrains/qodana-cdnet:2024.2-eap entrypoint: [""] cache: - key: qodana-2024.2-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG fallback_keys: - qodana-2024.2-$CI_DEFAULT_BRANCH- - qodana-2024.2- paths: - .qodana/cache variables: QODANA_TOKEN: $qodana_token - script: - qodana --baseline <path/to/qodana.sarif.json> --results-dir=$CI_PROJECT_DIR/.qodana/results --cache-dir=$CI_PROJECT_DIR/.qodana/cache

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

  1. In the TeamCity UI, navigate to the configuration page of a build where you would like to run Qodana.

  2. On the Build Configuration Settings page, navigate to the Build steps page.

  3. On the Build steps page, click the Add build step button.

  4. On the page that opens, select the Qodana runner.

  5. 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 inspection 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, specify either the Qodana for .NET or Qodana Community for .NET linter.

    • Version is by default set to Latest.

    • Inspection profile defines an inspection profile:

      • Recommended (default) is one of the default profiles.

      • Embedded profile lets you select a default profile, see the Existing Qodana profiles section for details.

      • Path to the IntelliJ profile 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 configures the arguments accepted by a Docker image, see the Shell commands section for details.

    • Additional Qodana arguments lets you extend the default Qodana functionality, see the Options section for details.

      In this field, specify the baseline feature using the --baseline <path/to/qodana.sarif.json> option.

    Configuring the Qodana runner

  6. 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>" \ -l jetbrains/qodana-dotnet:2024.2 \ --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:2024.2 \ --baseline /data/base/<path-relative-to-project-dir>/qodana.sarif.json

  1. In your IDE, navigate to the Problems tool window.

  2. In the Problems tool window, click the Server-Side Analysis tab.

  3. On the Server-Side Analysis tab, click the Try Locally button.

  4. On the dialog that opens, expand the Advanced configuration section and specify the path to the baseline file, and then click Run.

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

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@v2024.2 with: args: --linter,jetbrains/qodana-dotnet:2024.2 env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}

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

qodana: image: name: jetbrains/qodana-dotnet:2024.2 entrypoint: [""] cache: - key: qodana-2024.2-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG fallback_keys: - qodana-2024.2-$CI_DEFAULT_BRANCH- - qodana-2024.2- paths: - .qodana/cache variables: QODANA_TOKEN: $qodana_token script: - > qodana --diff-start=$CI_MERGE_REQUEST_TARGET_BRANCH_SHA \ --results-dir=$CI_PROJECT_DIR/.qodana/results \ --cache-dir=$CI_PROJECT_DIR/.qodana/cache artifacts: paths: - .qodana/results expose_as: 'Qodana report'

Here, the --diff-start option specifies a hash of the commit that will act as a base for comparison.

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>" \ -l jetbrains/qodana-dotnet:2024.2 \ --diff-start=<GIT_START_HASH>
docker run \    -v $(pwd):/data/project/ \    -e QODANA_TOKEN="<cloud-project-token>" \    jetbrains/qodana-dotnet:2024.2 \    --diff-start=<GIT_START_HASH>

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@v2024.2 with: args: --linter,jetbrains/qodana-cdnet:2024.2-eap env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}

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

qodana: image: name: jetbrains/qodana-cdnet:2024.2-eap entrypoint: [""] cache: - key: qodana-2024.2-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG fallback_keys: - qodana-2024.2-$CI_DEFAULT_BRANCH- - qodana-2024.2- paths: - .qodana/cache variables: QODANA_TOKEN: $qodana_token script: - > qodana --diff-start=$CI_MERGE_REQUEST_TARGET_BRANCH_SHA \ --results-dir=$CI_PROJECT_DIR/.qodana/results \ --cache-dir=$CI_PROJECT_DIR/.qodana/cache artifacts: paths: - .qodana/results expose_as: 'Qodana report'

Here, the --diff-start option specifies a hash of the commit that will act as a base for comparison.

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>" \ -l jetbrains/qodana-cdnet:2024.2-eap \ --diff-start=<GIT_START_HASH>
docker run \    -v $(pwd):/data/project/ \    -e QODANA_TOKEN="<cloud-project-token>" \    jetbrains/qodana-cdnet:2024.2-eap \    --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/cdnet>:2024.2<-eap> \ --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

✔

✔

✔

✔

✔

✔

✔

✔

✔

 

 

 

Frameworks and libraries

.NET Framework

.NET Core

Handlebars/Mustache

Less

Node.JS

NUnit

Pug/Jade

Sass/SCSS

Unity

Unreal Engine

Vue

Xunit

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

 

Databases and ORM

MongoDB

MySQL

Oracle

PostgreSQL

SQL

SQL server

✔

✔

✔

✔

✔

✔

 

Markup languages

HTML

XML

CSS

JSON and JSON5

RELAX NG

T4

XPath

XSLT

YAML

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

 

 

 

 

 

 

 

Scripting languages

Shell script

✔

 

Build management

MSBuild

✔

 

Qodana features

Baseline

Quality gate

Code coverage

License audit

Quick-fix

✔

✔

✔

✔

✔

✔

✔

 

 

 

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

** Supports Visual Basic inspections only.

Last modified: 13 September 2024
PythonJava, Kotlin, and Groovy