Qodana 2024.1 Help

Qodana for .NET

official project

Qodana for .NET linter languages

Qodana for .NET is based on Rider and provides static analysis for .NET projects. It brings all the smarts from Rider, which help you:

  • Detect anomalous code and probable bugs

  • Eliminate dead code

  • Highlight spelling problems

  • Improve overall code structure

  • Introduce coding best practices

  • Upload inspection results to Qodana Cloud

Qodana for .NET provides inspections for the C, C++, C#, VB.NET, JavaScript, and TypeScript programming languages. C and C++ inspections of Qodana for .NET are limited by projects containing .sln solution files or .csproj project files.

Starting from version 2023.3, the functionality of .NET Framework-based project analysis is available in the native mode of Qodana.

Supported technologies

Qodana for .NET provides inspections for the following technologies.

Programming languages

C#

C

C++

JavaScript

TypeScript

VB.NET

Markup languages

CSS

HTML

JSON and JSON5

RELAX NG

T4

XML

XPath

XSLT

YAML

Scripting languages

Shell script

Databases and ORM

MongoJS

MySQL

Oracle

PostgreSQL

SQL

SQL server

Build management

MSBuild

Frameworks and libraries

.NET Framework

.NET Core

Handlebars/Mustache

Less

Node.JS

NUnit

Pug/Jade

Sass/SCSS

Unity

Unreal Engine

Vue

Xunit

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

Supported features

The Qodana for .NET linter provides the following Qodana features:

Feature

Available under licenses

Baseline

Ultimate and Ultimate Plus

Code coverage

Ultimate and Ultimate Plus

Quality gate

Ultimate and Ultimate Plus

License audit

Ultimate Plus

Analyze a project locally

Install project dependencies (non-native mode)

Qodana for .NET is suitable for analyzing .NET projects, and the Dockerized version of this linter 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 for .NET container filesystem.

In case a project requires a different version of the SDK, you can set it up before running the analysis using the bootstrap field 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

Build the project

Build the project before inspecting it using Qodana. You can do it by using the bootstrap option of the qodana.yaml file contained in your project directory.

Configure Qodana

Starting from version 2023.3 of Qodana, the native mode is the recommended method for running the Qodana for .NET linter. We recommend running the native mode on the same machine where you build a project because this can guarantee that Qodana has access to private NuGet feeds.

Specify a 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 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:

--property=qodana.net.solution=MySolution.sln

Alternatively, 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.sln

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

--property=qodana.net.project=MyProject.csproj

Alternatively, you can specify the project filename in the qodana.yaml file using the project option:

dotnet: project: MyProject.csproj
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.

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 --property configuration option. For example, use this to switch to the Release configuration:

--property=qodana.net.configuration=Release

Alternatively, you can specify the configuration in qodana.yaml:

dotnet: configuration: Release

By default, the solution platform is set to Any CPU .You can override this using the --property option:

--property=qodana.net.platform=x86

Alternatively, you can specify the platform in qodana.yaml:

dotnet: platform: x86

Roslyn analyzers

.NET projects have Roslyn analyzers as separate inspections, and you can configure them using the EditorConfig files. To disable them, 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

Another configuration example is available on GitHub.

Run Qodana

You can run Qodana CLI in the native mode, which is the recommended method for the Qodana for .NET linter. Alternatively, you can use the Docker command from the Docker image tab.

Assuming that you have already installed Qodana CLI on your machine and followed the recommendations from this section, you can 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 you can save the ide: QDNET configuration, and then run Qodana using this command:

qodana scan

If you plan to use private NuGet feeds, we recommend running the native mode on the same machine where you build a project because this can guarantee that Qodana has access to private NuGet feeds.

To start, pull the image from Docker Hub (only necessary to get the latest version):

docker pull jetbrains/qodana-dotnet:2024.1

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 \    --show-report

Open Qodana Cloud in your browser to examine inspection results.

You can run Qodana for .NET using private NuGet feeds:

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> \    -e QODANA_NUGET_NAME=<name-of-private-NuGet-feed> \    jetbrains/qodana-dotnet:2024.1 \    --show-report

Configuration examples for using private NuGet feeds are available on the GitHub website.

Analyze pull requests

You can run incremental analysis on a change set like merge or pull requests.

For example, if you just finished work within a particular commit and would like to analyse the changes, you can employ the --diff-start option:

qodana scan \    -e QODANA_TOKEN="<cloud-project-token>" \    --diff-start=<GIT_START_HASH>
docker run \    -v $(pwd):/data/project/ \    -e QODANA_TOKEN="<cloud-project-token>" \    jetbrains/qodana-dotnet:2024.1 \    --diff-start=<GIT_START_HASH>

If you would like to inspect a set of changes between two commits, you can employ both --diff-start and --diff-end options:

qodana scan \    -e QODANA_TOKEN="<cloud-project-token>" \    --diff-start=<GIT_START_HASH> \    --diff-end=<GIT_END_HASH>
docker run \    -v $(pwd):/data/project/ \    -e QODANA_TOKEN="<cloud-project-token>" \    jetbrains/qodana-dotnet:2024.1 \    --diff-start=<GIT_START_HASH> \    --diff-end=<GIT_END_HASH>

Next steps

Last modified: 16 April 2024