Qodana 2024.1 Help

.NET

All Qodana linters are based on 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](https://learn.microsoft.com/en-us/dotnet/standard/frameworks#net-5-os-specific-tfms), the only option in this case is to run the Qodana for .NET linter in the [native mode](native-mode.md).

If you run Qodana for .NET in the native mode, you should handle SDK availability for Rider.

The Dockerized version of Qodana for .NET provides the following SDK versions:

  • 6.0.417,

  • 7.0.404,

  • 8.0.100.

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.

You can run Qodana using the Qodana Scan GitHub action.

  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 create the .github/workflows/code_quality.yml file. This file will be used for further examples.

  1. Make sure that these plugins are installed on your Jenkins instance:

    • 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. Create a Multibranch Pipeline project as described on the Jenkins documentation portal.

  3. In the root directory of your project repository, save the Jenkinsfile.

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

  2. In the root directory of your project, create the .gitlab-ci.yml file that will contain configurations for running Qodana.

Assuming that you have already created your project and build configuration, follow the steps below.

  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.

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

You have two options to run Qodana locally: you can either run Qodana CLI or directly use the Docker image of Qodana. As Qodana linters are distributed in Docker containers, Docker needs to be installed on your local machine. If you are using Linux, you should be able to run Docker under your current non-root user, check the installation page for details.

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

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

    Configuring Qodana in the Run Qodana dialog

    This dialog contains the following components:

    Name

    Description

    The qodana.yaml file

    In the text field, you can set up code analysis used by Qodana in this file. You can learn more about available configuration options

    The Send inspection results to Qodana Cloud option

    If you want to send reports to Qodana Cloud, you can check this option and paste the project token generated in Qodana Cloud

    The Save qodana.yaml in project root option

    By checking this option, you can save the Qodana configuration made on this dialog to the qodana.yaml file in the project root of your project

    The Use Qodana analysis baseline option

    Using the baseline feature, you can skip analysis for specific problems

    Click Run for analyzing your code.

  3. On the Server-Side Analysis tab of the Problems tool window, see the inspection results.

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:

This is the GitHub Actions configuration sample invoking 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.1 with: args: --no-build env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}

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.1-eap' } } stages { stage('Qodana') { steps { sh ''' qodana \ --no-build ''' } } } }
qodana: image: name: jetbrains/qodana-cdnet:2024.1-eap entrypoint: [""] cache: - key: qodana-2024.1-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG fallback_keys: - qodana-2024.1-$CI_DEFAULT_BRANCH- - qodana-2024.1- 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'

Using the Additional Qodana arguments field of the Qodana runner configuration, you can configure the --no-build option.

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

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

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

    Configuring Qodana in the Run Qodana dialog

    This dialog contains the following components:

    Name

    Description

    The qodana.yaml file

    In the text field, you can set up code analysis used by Qodana in this file. You can learn more about available configuration options

    The Send inspection results to Qodana Cloud option

    If you want to send reports to Qodana Cloud, you can check this option and paste the project token generated in Qodana Cloud

    The Save qodana.yaml in project root option

    By checking this option, you can save the Qodana configuration made on this dialog to the qodana.yaml file in the project root of your project

    The Use Qodana analysis baseline option

    Using the baseline feature, you can skip analysis for specific problems

    Click Run for analyzing your code.

  3. On the Server-Side Analysis tab of the Problems tool window, see the inspection results.

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,

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

  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 create the .github/workflows/code_quality.yml file.

  3. 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.1 with: args: --ide,QDNET env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}

    This configuration invokes the native mode using:

    with:    args: --ide,QDNET

Save this snippet to the Jenkinsfile:

pipeline { environment { QODANA_TOKEN=credentials('qodana-token') } agent { docker { args ''' -v "${WORKSPACE}":/data/project --entrypoint="" ''' image 'jetbrains/qodana-dotnet:2024.1' } } stages { stage('Qodana') { steps { sh '''qodana''' } } } }
qodana: image: name: jetbrains/qodana-dotnet:2024.1 entrypoint: [""] cache: - key: qodana-2024.1-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG fallback_keys: - qodana-2024.1-$CI_DEFAULT_BRANCH- - qodana-2024.1- 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'

See the Prepare your software section for details.

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.

  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 create the .github/workflows/code_quality.yml file.

  3. 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.1 env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}

Save this snippet to the Jenkinsfile:

pipeline { environment { QODANA_TOKEN=credentials('qodana-token') } agent { docker { args ''' -v "${WORKSPACE}":/data/project --entrypoint="" ''' image 'jetbrains/qodana-dotnet:2024.1' } } stages { stage('Qodana') { steps { sh '''qodana''' } } } }
qodana: image: name: jetbrains/qodana-dotnet:2024.1 entrypoint: [""] cache: - key: qodana-2024.1-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG fallback_keys: - qodana-2024.1-$CI_DEFAULT_BRANCH- - qodana-2024.1- 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'

See the Prepare your software section for details.

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

  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.

  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 create the .github/workflows/code_quality.yml file.

  3. 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.1 env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}

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.1-eap' } } stages { stage('Qodana') { steps { sh '''qodana''' } } } }
qodana: image: name: jetbrains/qodana-cdnet:2024.1-eap entrypoint: [""] cache: - key: qodana-2024.1-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG fallback_keys: - qodana-2024.1-$CI_DEFAULT_BRANCH- - qodana-2024.1- 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'

See the Prepare your software section for details.

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

Specify a solution

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.

YAML file

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

The Qodana for .NET linter uses the --property option, while the Qodana Community for .NET linter uses the --solution option 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.1 \    --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.1-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.1 \    --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.1-eap \    --project=<relative-path-to-project-file>

Configure a solution

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.

YAML file

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
Docker

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.1 \    --property=qodana.net.configuration=Release
docker run \    -v <source-directory>/:/data/project/ \    -e QODANA_TOKEN="<cloud-project-token>" \    jetbrains/qodana-cdnet:2024.1-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.1 \    --property=qodana.net.platform=x86
docker run \    -v <source-directory>/:/data/project/ \    -e QODANA_TOKEN="<cloud-project-token>" \    jetbrains/qodana-cdnet:2024.1-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.1 \

Other configuration examples are available on our GitHub repository.

  1. In the local filesystem, create the folder that will contain cache. For example, it can be C:/Temp/QodanaCache.

  2. Run Qodana using the --cache-dir C:/Temp/QodanaCache option.

  3. Copy all NuGet packages contained by default in the %userprofile%\.nuget\packages folder to C:/Temp/QodanaCache/nuget. If you have a custom package folder, copy packages from that folder instead of %userprofile%\.nuget\packages.

  4. Run Qodana using the --cache-dir C:/Temp/QodanaCache once more.

Explore analysis results

JetBrains IDEs

You can get the latest Qodana report in 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. By enabling the Always load most relevant Qodana report option, you get actual reports automatically retrieved 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.

Qodana Cloud

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

Adjust the scope of analysis

Qodana for .NET

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. You can configure Roslyn analyzers as explained in the section. 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.1 \    --profile-path /data/project/myprofiles/<inspection-profile.xml>

Qodana Community for .NET

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 configure Roslyn analyzers, see the section.

To disable Roslyn analyzers, in the solution's .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>

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.

Enable the baseline

You can skip analysis for specific problems using the baseline feature.

JetBrains IDEs

  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.

GitHub Actions

This snippet contains the args: --baseline,qodana.sarif.json line that specifies the path to the SARIF-formatted file containing a baseline:

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.1 with: args: --baseline,qodana.sarif.json env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}

Command line

In these snippets, the --baseline option configures the path to the SARIF-formatted file containing a baseline:

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

Enable 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

Analyze pull requests

GitHub Actions

Because the Qodana Scan GitHub action automatically analyzes all pull requests, you can use.

Local run

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:

docker run \    -v $(pwd):/data/project/ \    -e QODANA_TOKEN="<cloud-project-token>" \    jetbrains/qodana-<dotnet/cdnet>:2024.1<-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.1<-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

✔ All from the list

✔

✔

✔

❌

❌

❌

Frameworks and libraries

.NET Framework

.NET Core

Handlebars/Mustache

Less

Node.JS

NUnit

Pug/Jade

Sass/SCSS

Unity

Unreal Engine

Vue

Xunit

✔ All from the list

❌ None

Databases and ORM

MongoDB

MySQL

Oracle

PostgreSQL

SQL

SQL server

✔ All from the list

❌ None

Markup languages

HTML

XML

CSS

JSON and JSON5

RELAX NG

T4

XPath

XSLT

YAML

✔ All from the list

✔

✔

❌

❌

❌

❌

❌

❌

❌

Scripting languages

Shell script

✔

❌

Build management

MSBuild

✔

❌

Qodana features

Baseline

Quality gate

Code coverage

License audit

✔ All from the list

✔

✔

❌

❌

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

** Supports Visual Basic inspections only.

Last modified: 26 July 2024
PythonJVM