Qodana Community for .NET
The Docker image for the Qodana Community for .NET linter is provided to support different usage scenarios:
Running the analysis on a regular basis as part of your continuous integration (CI-based execution)
Single-shot analysis (for example, performed locally).
You can run the Qodana Community for .NET linter using two methods. Qodana CLI is the easiest method. If necessary, check the installation page to install Qodana CLI. Alternatively, you can use the Docker commands from the Docker image tab.
note
This linter requires the Qodana Cloud project token.
note
The Qodana Community for .NET linter does not support profiles and their configuration options.
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
.DotSettingsfiles)Files, file masks, and regions with generated code, where the code analysis is partly disabled (this can only be configured using
.DotSettingsfiles)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. If you want to disable Roslyn analyzers, you can do it in the solution's .DotSettings file, for example:
<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=erroror you can disable the Redundant argument with default value inspection with the following line:
resharper_redundant_argument_default_value_highlighting=nonetip
Inspection settings from
.editorconfigfiles 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.
note
Pull the image from Docker Hub (only necessary to update to the
latestversion):$docker pull jetbrains/qodana-cdnet:2024.1-eapRun the following command to start inspecting your source code:
$docker run \ -v <source-directory>/:/data/project/ \ -v <output-directory>/:/data/results/ \ -e QODANA_TOKEN="<cloud-project-token>" \ jetbrains/qodana-cdnet:2024.1-eapwhere
source-directoryandoutput-directoryare full local paths to, respectively, the project source code directory and the analysis results directory. TheQODANA_TOKENvariable refers to the project token required by the linter license. Using the linter without the project token is useless because it does not support showing inspection results locally.
If you don't need the user interface and prefer to review raw data, use the following command:
$docker run \ -v <source-directory>/:/data/project/ \ -v <output-directory>/:/data/results/ \ -e QODANA_TOKEN="<cloud-project-token>" \ jetbrains/qodana-cdnet:2024.1-eap
The output-directory will contain the inspection report.
If you run the analysis several times in a row, make sure you've cleaned the results directory before using it in docker run again.
In the project root directory, run this command to inspect your code and view the inspection report locally:
$qodana scan \ -e QODANA_TOKEN="<cloud-project-token>" \ -l jetbrains/qodana-cdnet:2024.1-eap \ --show-report
If you don't need the user interface and prefer to review raw data, use the following command:
$qodana scan \ -e QODANA_TOKEN="<cloud-project-token>" \ -l jetbrains/qodana-cdnet:2024.1-eap \ --results-dir <output-directory>
The output-directory specifies the directory where the SARIF-formatted report will be saved. The QODANA_TOKEN variable refers to the project token required by the license.
Use the following command as a task in a generic shell executor:
$docker run \ -v <source-directory>/:/data/project/ \ -v <output-directory>/:/data/results/ \ -e QODANA_TOKEN="<cloud-project-token>" \ jetbrains/qodana-cdnet:2024.1-eap
where source-directory and output-directory are full paths to, respectively, the project source code directory and the analysis results directory. The QODANA_TOKEN variable refers to the project token required by the Ultimate and Ultimate Plus linters.
Consider using the Quality gate feature to make the build fail when a certain number of problems is reached and the Baseline feature to compare each new linter run to some initial run selected as a baseline.
tip
For details on available CI integrations, see Integration with CI systems.
Run this command in the project root directory:
$qodana scan \ -e QODANA_TOKEN="<cloud-project-token>" \ -l jetbrains/qodana-cdnet:2024.1-eap \ --results-dir <output-directory>
This will save inspection results to the directory specified by output-directory.
You can also apply the Quality gate feature to make the build fail when a certain number of problems is reached by using the --fail-threshold option.
The Baseline feature compares each new Qodana Community for .NET run to some initial run using the --baseline and --baseline-include-absent options.
tip
For details on available CI integrations, see Integration with CI systems.
note
This feature is in experimental mode, which means that its operation can be unstable.
This feature requires that you specify the Qodana Community for .NET name either in the qodana.yaml file, or using the args configuration option of GitHub, for example:
args: --linter,qodana-cdnet:2024.1-eapIn GitHub, Qodana is implemented as the Qodana Scan GitHub Action.To configure the Qodana Scan GitHub Action, save the .github/workflows/code_quality.yml file containing the workflow configuration:
name: Qodana
on:
workflow_dispatch:
pull_request:
push:
branches:
- main
- 'releases/*'
jobs:
qodana:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- name: 'Qodana Scan'
uses: JetBrains/qodana-action@v2024.1To authorize in Qodana Cloud and forward reports to it, follow these steps:
In the GitHub UI, create the
QODANA_TOKENencrypted secret and save the project token as its value.In a GitHub workflow, add this snippet to invoke the
Qodana Scanaction:- name: 'Qodana Scan' uses: JetBrains/qodana-action@v2024.1 env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
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 using the --solution option and a relative path to a solution file. For example, to make Qodana always analyze the MySolution.sln solution file, you can use:
--solution=MySolution.slnAlternatively, you can specify the solution filename in the qodana.yaml file using the solution option and a relative path to a solution file:
dotnet:
solution: MySolution.slnIf your project contains no solution files and multiple project files, you need to use the --project option and a relative path to a project file. For example, for the MyProject.csproj project file you can use:
--project=MyProject.csprojAlternatively, you can specify the project filename in the qodana.yaml file using the project option:
dotnet:
project: MyProject.csprojA solution configuration defines which projects in the solution are build, and which project configurations are used for specific projects within the solution.
Each newly-created solution includes the Debug and Release configurations, which can be complemented by your custom configurations.
You can switch configurations of the current solution using the --configuration option. For example, use this to switch to the Release configuration:
--configuration=ReleaseAlternatively, you can specify the configuration in qodana.yaml:
dotnet:
configuration: ReleaseBy default, the solution platform is set to Any CPU .You can override this using the --platform option:
--platform=x86Alternatively, you can specify the platform in qodana.yaml:
dotnet:
platform: x86According 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.
Thanks for your feedback!