.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.
Before you 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.
Navigate to Qodana Cloud and create an account there.
In Qodana Cloud, create an organization, a team, and a project.
On the project card, you can find the project token that you will be using further in this section.
A project token is required for the Qodana for .NET linter and optional for the Qodana Community for .NET linter.
SDK version
If you project targets the .NET framework or OS-specific TFMs, the only option in this case is to run the Qodana for .NET linter in native mode.
If you run Qodana for .NET in native mode, you should install the SDK to the default location in your operating system so that Rider can have access to it.
The Dockerized version of Qodana for .NET provides versions 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:
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.
On the
tab of the GitHub UI, create theQODANA_TOKEN
encrypted secret and save the project token as its value.On the
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.
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 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:
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:
In the root directory of your project repository, save this configuration to the Jenkinsfile
:
In the TeamCity UI, navigate to the configuration page of a build where you would like to run Qodana.
- page, navigate to the
On the
page, click the button.On the page that opens, select the
runner.On the
page, click and configure the runner:uniquely identifies this step among other build steps.
uniquely identifies this step among other build steps.
configures the build condition that will trigger this build step.
TeamCity documentation for details. You can leave this field empty if the
sets the directory for the build process, see theCheckout directory
parameter is specified on the tab.uniquely identifies the report to let you distinguish between multiple reports when several inspection steps are configured within a single build.
The Test tab of the TeamCity UI. Using this option, you can view codebase problems along with other problems detected.
checkbox configures Qodana report availability in the- configures the
Here, specify either the Qodana for .NET or Qodana Community for .NET linter.
Here, specify the
Qodana Community for .NET
linter.
is by default set toLatest
.- defines an
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.
project token generated in Qodana Cloud.
configures aShell commands section for details.
configures the arguments accepted by a Docker image, see theOptions section for details.
lets you extend the default Qodana functionality, see theIn this field, specify the
--no-build
option.
Click the
button.
Run Qodana
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.
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:
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:
This configuration invokes native mode using:
Run this command in the project root directory:
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:
In Rider, navigate to
.On the
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 option using a project token.
Click
for analyzing your code.In the inspection results.
tool window, see the
Container mode is available for the Qodana for .NET linter; however, we recommend 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:
In the root directory of your project repository, save the Jenkinsfile
containing the following configuration:
In the root directory of your project, create the .gitlab-ci.yml
and save the following configuration there:
In the TeamCity UI, navigate to the configuration page of a build where you would like to run Qodana.
- page, navigate to the
On the
page, click the button.On the page that opens, select the
runner.On the
page, click and configure the runner:uniquely identifies this step among other build steps.
uniquely identifies this step among other build steps.
configures the build condition that will trigger this build step.
TeamCity documentation for details. You can leave this field empty if the
sets the directory for the build process, see theCheckout directory
parameter is specified on the tab.uniquely identifies the report to let you distinguish between multiple reports when several inspection steps are configured within a single build.
The Test tab of the TeamCity UI. Using this option, you can view codebase problems along with other problems detected.
checkbox configures Qodana report availability in the- configures the
Here, specify either the Qodana for .NET or Qodana Community for .NET linter.
is by default set toLatest
.- defines an
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.
project token generated in Qodana Cloud.
configures aShell commands section for details.
configures the arguments accepted by a Docker image, see theOptions section for details.
lets you extend the default Qodana functionality, see the
Click the
button.
Start local analysis with source-directory
pointing to the root of your project and QODANA_TOKEN
referring to the project token:
In Rider, navigate to
.On the
dialog, you can configure:Options used by Qodana and configured by the
qodana.yaml
file. Here, comment out the line containingide: QDNET
.The option using a project token.
Click
for analyzing your code.In the inspection results.
tool window, see the
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:
In the root directory of your project repository, save this snippet to the Jenkinsfile
:
In the root directory of your project, create the .gitlab-ci.yml
and save the following configuration there:
In the TeamCity UI, navigate to the configuration page of a build where you would like to run Qodana.
- page, navigate to the
On the
page, click the button.On the page that opens, select the
runner.On the
page, click and configure the runner:uniquely identifies this step among other build steps.
uniquely identifies this step among other build steps.
configures the build condition that will trigger this build step.
TeamCity documentation for details. You can leave this field empty if the
sets the directory for the build process, see theCheckout directory
parameter is specified on the tab.uniquely identifies the report to let you distinguish between multiple reports when several inspection steps are configured within a single build.
The Test tab of the TeamCity UI. Using this option, you can view codebase problems along with other problems detected.
checkbox configures Qodana report availability in the- configures the
Here, specify either the Qodana for .NET or Qodana Community for .NET linter.
is by default set toLatest
.- defines an
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.
project token generated in Qodana Cloud.
configures aShell commands section for details.
configures the arguments accepted by a Docker image, see theOptions section for details.
lets you extend the default Qodana functionality, see the
Click the
button.
Start local analysis with source-directory
pointing to the root of your project and QODANA_TOKEN
referring to the project token:
In Rider, navigate to
.On the
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 option using a project token.
Click
for analyzing your code.In the inspection results.
tool window, see the
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:
If your project contains no solution files and multiple project files, you need to employ a 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:
If your project contains no solution files and multiple project files, you need to employ a project file using the --property
and --project
options:
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:
By default, the solution platform is set to Any CPU
, and you can override it, for example:
You can apply a configuration using the --property
and --configuration
options:
By default, the solution platform is set to Any CPU
, and you can override it as shown below:
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, 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:
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:
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:
Explore analysis results
You can load the latest Qodana report from Qodana Cloud to your IDE as explained below.
In your IDE, navigate to
.On the
dialog, click .This will redirect you to the authentication page.
Select the Qodana Cloud project to link your local project with.
If you check the
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 analysis results.
tab of the tool window, you can view the
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.
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:
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:
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:
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
page of ReSharper options.Target languages (
).
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:
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:
For example, you can change the severity level of the Possible 'System.NullReferenceException'
inspection to Error
with the following line:
or you can disable the Redundant argument with default value
inspection with the following line:
You can find EditorConfig property for each inspection on pages in the Code inspection index section as well as on the Index of EditorConfig properties page. — just use the browser search to find the property for the desired inspection.
Enabling the baseline feature
You can skip analysis for specific problems by using the baseline feature. Information about a baseline is contained in a SARIF-formatted file.
Select how you would like to run the Qodana for .NET linter with the baseline feature:
You can run the Qodana for .NET linter in the native mode:
Save this snippet to the .github/workflows/code_quality.yml
file:
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:
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:
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:
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:
In the root directory of your project, save this snippet to the .gitlab-ci.yml
file:
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.
- page, navigate to the
On the
page, click the button.On the page that opens, select the
runner.On the
page, click and configure the runner:uniquely identifies this step among other build steps.
uniquely identifies this step among other build steps.
configures the build condition that will trigger this build step.
TeamCity documentation for details. You can leave this field empty if the
sets the directory for the build process, see theCheckout directory
parameter is specified on the tab.uniquely identifies the report to let you distinguish between multiple reports when several inspection steps are configured within a single build.
The Test tab of the TeamCity UI. Using this option, you can view codebase problems along with other problems detected.
checkbox configures Qodana report availability in the- configures the
Here, specify either the Qodana for .NET or Qodana Community for .NET linter.
is by default set toLatest
.- defines an
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.
project token generated in Qodana Cloud.
configures aShell commands section for details.
configures the arguments accepted by a Docker image, see theOptions section for details.
lets you extend the default Qodana functionality, see theIn this field, specify the baseline feature using the
--baseline <path/to/qodana.sarif.json>
option.
Click the
button.
Choose how you would like to run the baseline feature from the command line:
In your IDE, navigate to the
tool window.In the
tool window, click the tab.On the
tab, click the button.On the dialog that opens, expand the
section and specify the path to the baseline file, and then click .
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:
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:
In the root directory of your project, save this snippet to the .gitlab-ci.yml
file:
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.
- page, navigate to the
On the
page, click the button.On the page that opens, select the
runner.On the
page, click and configure the runner:uniquely identifies this step among other build steps.
uniquely identifies this step among other build steps.
configures the build condition that will trigger this build step.
TeamCity documentation for details. You can leave this field empty if the
sets the directory for the build process, see theCheckout directory
parameter is specified on the tab.uniquely identifies the report to let you distinguish between multiple reports when several inspection steps are configured within a single build.
The Test tab of the TeamCity UI. Using this option, you can view codebase problems along with other problems detected.
checkbox configures Qodana report availability in the- configures the
Here, specify either the Qodana for .NET or Qodana Community for .NET linter.
is by default set toLatest
.- defines an
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.
project token generated in Qodana Cloud.
configures aShell commands section for details.
configures the arguments accepted by a Docker image, see theOptions section for details.
lets you extend the default Qodana functionality, see theIn this field, specify the baseline feature using the
--baseline <path/to/qodana.sarif.json>
option.
Click the
button.
Choose how you would like to run the baseline feature from the command line:
In your IDE, navigate to the
tool window.In the
tool window, click the tab.On the
tab, click the button.On the dialog that opens, expand the
section and specify the path to the baseline file, and then click .
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:
You can configure quality gates for the total number of project problems by saving this snippet to the qodana.yaml
file:
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:
In the root directory of your project, save the .gitlab-ci.yml
file containing the following snippet:
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:
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:
In the root directory of your project, save the .gitlab-ci.yml
file containing the following snippet:
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:
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:
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 | ✔ ✔ ✔ ✔ ✔ | ✔ ✔
|
* C and C++ inspections are applicable for projects containing .sln
files.
** Supports Visual Basic inspections only.