.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 | |
---|---|---|---|---|
Qodana for .NET | Ultimate and Ultimate Plus | A native solution and a Docker image | C#, C/C++, VB.NET, JavaScript, TypeScript | |
Qodana Community for .NET | 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.
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.
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 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
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.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.3 with: # args: --linter,jetbrains/qodana-dotnet:2024.3 # args: --linter,jetbrains/qodana-cdnet:2024.3-eap env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
This configuration sample will be modified throughout the section.
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, 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 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 jetbrains/qodana-dotnet:2024.3
$docker pull jetbrains/qodana-cdnet:2024.3-eap
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.3
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.3-eap'
}
}
stages {
stage('Qodana') {
steps {
sh '''
qodana \
--no-build
'''
}
}
}
}
qodana:
image:
name: jetbrains/qodana-cdnet:2024.3-eap
entrypoint: [""]
cache:
- key: qodana-2024.3-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG
fallback_keys:
- qodana-2024.3-$CI_DEFAULT_BRANCH-
- qodana-2024.3-
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'
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 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 theqodana.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 Shell commands section for details.
Additional Qodana arguments let you extend the default Qodana functionality, see the Options section for details.
In this field, specify the
--no-build
option.
Click the Save button.
$qodana scan \ -e QODANA_TOKEN="<cloud-project-token>" \ jetbrains/qodana-cdnet:2024.3-eap \ --no-build
$docker run \ -v <source-directory>/:/data/project/ \ -e QODANA_TOKEN="<cloud-project-token>" \ jetbrains/qodana-cdnet:2024.3-eap \ --no-build
note
tip
Check out the Configure root and non-root users section to learn more about how root and non-root users can run Qodana.
note
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.
note
If you plan to use private NuGet feeds, it is advised to run native mode on the same machine where you build a project because this can guarantee that Qodana has access to private NuGet feeds.
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 native mode by adding this line to the qodana.yaml
file:
ide: QDNET
Alternatively, you can implement native mode configuration as shown in examples below.
To inspect the main
branch, release branches and the pull requests coming to your repository in 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.3
with:
args: --ide,QDNET
env:
QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
This configuration invokes 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
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. You can see that native mode is already configured.The Send inspection 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 inspection results.
Container mode is available for the Qodana for .NET linter; however, it is advised that you use native mode.
To analyze the main
branch, release branches and the pull requests coming to your repository in 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.3
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.3'
}
}
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.3
entrypoint: [""]
cache:
- key: qodana-2024.3-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG
fallback_keys:
- qodana-2024.3-$CI_DEFAULT_BRANCH-
- qodana-2024.3-
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'
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 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 theqodana.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 Shell commands section for details.
Additional Qodana arguments let you extend the default Qodana functionality, see the Options section for details.
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.3
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. Here, comment out the line containingide: QDNET
.The Send inspection 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 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 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.3
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.3-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.3-eap
entrypoint: [""]
cache:
- key: qodana-2024.3-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG
fallback_keys:
- qodana-2024.3-$CI_DEFAULT_BRANCH-
- qodana-2024.3-
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'
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 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 theqodana.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 Shell commands section for details.
Additional Qodana arguments let you extend the default Qodana functionality, see the Options section for details.
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.3-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. You can see that native mode is already configured.The Send inspection 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 inspection results.
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.3 \
--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.3-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.3 \
--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.3-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.3 \
--property=qodana.net.configuration=Release
docker run \
-v <source-directory>/:/data/project/ \
-e QODANA_TOKEN="<cloud-project-token>" \
jetbrains/qodana-cdnet:2024.3-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.3 \
--property=qodana.net.platform=x86
docker run \
-v <source-directory>/:/data/project/ \
-e QODANA_TOKEN="<cloud-project-token>" \
jetbrains/qodana-cdnet:2024.3-eap \
--platform=x86
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, 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.3 \
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 in 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"
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 Inspection report section.
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.
tip
You can customize Qodana profiles using configurations in YAML and XML formats. To learn more about configuration basics, visit the Configure Qodana your way section of the documentation.
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.3 \ --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, 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>
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
tip
Inspection settings from
.editorconfig
files have higher priority than the settings configured on the Code Inspection | Inspection Severity page of InspectCode options.
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.
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@v2024.3
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 the analysis results and reconfigure the analysis. See the Inspection report 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@v2024.3
with:
args: --baseline,<path/to/qodana.sarif.json>,--linter,jetbrains/qodana-dotnet:2024.3
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.3'
}
}
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.3
entrypoint: [""]
cache:
- key: qodana-2024.3-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG
fallback_keys:
- qodana-2024.3-$CI_DEFAULT_BRANCH-
- qodana-2024.3-
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.
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 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 theqodana.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 Shell commands section for details.
Additional Qodana arguments let 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.
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.3 \ --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.3 \ --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@v2024.3
with:
args: --baseline,<path/to/qodana.sarif.json>,--linter,jetbrains/qodana-cdnet:2024.3-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.3-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.3-eap
entrypoint: [""]
cache:
- key: qodana-2024.3-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG
fallback_keys:
- qodana-2024.3-$CI_DEFAULT_BRANCH-
- qodana-2024.3-
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.
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 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 theqodana.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 Shell commands section for details.
Additional Qodana arguments let 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.
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-cdnet:2024.3-eap \ --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:2024.3-eap \ --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.
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
This feature is supported only by 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@v2024.3
with:
args: --linter,jetbrains/qodana-dotnet:2024.3
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.3
entrypoint: [""]
cache:
- key: qodana-2024.3-$CI_DEFAULT_BRANCH-$CI_COMMIT_REF_SLUG
fallback_keys:
- qodana-2024.3-$CI_DEFAULT_BRANCH-
- qodana-2024.3-
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.3 \ --diff-start=<GIT_START_HASH>
$docker run \ -v $(pwd):/data/project/ \ -e QODANA_TOKEN="<cloud-project-token>" \ jetbrains/qodana-dotnet:2024.3 \ --diff-start=<GIT_START_HASH>
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.3 \
--no-statistics=true
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 | ✔ ✔ ✔ ✔ ✔ | ✔ ✔
|
* C and C++ inspections are applicable for projects containing .sln
files.
** Supports Visual Basic inspections only.