All C# and VB.NET code analyzers present in SonarLint for Visual Studio, SonarQube and SonarCloud are being developed here. These analyzers rely on Roslyn 1.3.2 API.
- Clone this repository
- Download sub-modules
git submodule update --init --recursive
- Run
.\scripts\build\dev-build.ps1 -build -test
In general, it is best to run commands from the Visual Studio Developer Command Prompt (if you're using ConEmu, you can setup a console task like -new_console:C:\Workspace\sonar-dotnet cmd /k ""c:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools\VsDevCmd.bat" "
- it starts the Developer Console inside the folder C:\Workspace\sonar-dotnet
)
- Visual Studio 2022 or Rider
- When using Visual Studio, ensure to install the following Workloads:
- ASP.NET and web development
- .NET desktop development
- Visual Studio extension development
- Ensure to install Individual components:
- .NET Framework 4.8 SDK
- .NET Framework 4.8 Targeting pack
- .NET SDK
- .NET Compiler Platform SDK
- Install also:
- .NET Core 3.1 SDK
- .NET 3.5 SDK (SP1)
- The following environment variables must be set:
- JAVA_HOME
- MSBUILD_PATH - path to the MSBuild.exe executable (MSBuild 16)
- NUGET_PATH - path to the nuget.exe executable (related to the plugin integration tests)
- ORCHESTRATOR_CONFIG_URL - url to orchestrator.properties file (for integration tests) in uri form (i.e. file:///c:/something/orchestrator.properties)
- RULE_API_PATH - path to folder containing the rule api jar
- PATH - the system PATH variable must contain:
- the path to the dotnet core installation folder
- the path to the MSBuild bin folder
- the path to the visual studo installer folder (for vswhere.exe)
- the path to the nuget executable folder (e.g. C:\Program Files\nuget)
- the path to the JDK bin folder
- %M2_HOME%\bin
- the path to the SonarScanner for .NET folder and to the Scanner CLI
- Open
analyzers/SonarAnalyzer.sln
You can run the Unit Tests via the Test Explorer of Visual Studio or using .\scripts\build\dev-build.ps1 -test
For most projects, there are JSON files in the expected folder with expected issues. One JSON file per rule.
For the ManuallyAddedNoncompliantIssues project, we verify for each file the issues for one specific rule - like we do for Unit Tests. The first occurrence must specify the rule ID (// Noncompliant (S9999)
), and the next occurrences can only have // Noncompliant
. If multiple rules are raising issues in that file, they will be ignored. The framework can only verify one rule per file. Look at some files inside the ManuallyAddedNoncompliantIssues project.
The same applies for ManuallyAddedNoncompliantIssuesVB.
For details on how the parsing works, read the regression-test.ps1 script.
To run the ITs you will need to follow this pattern:
- Make sure the project is built: Integration tests don't build the analyzer, but use the results of the latest build (debug or release)
- Open the
Developer Command Prompt for VS2022
from the start menu - Go to
PATH_TO_CLONED_REPOSITORY/analyzers/its
- Run
powershell
- Run
.\regression-test.ps1
Notes:
- You can run a single rule using the
-ruleId
parameter (e.g..\regression-test.ps1 -ruleId S1234
) - You can run a single project using the
-project
parameter (e.g..\regression-test.ps1 -project Nancy
)
If the script ends with SUCCESS: No differences were found!
(or exit code 0), this means the changes you have made haven't impacted any rule.
If the script ends with ERROR: There are differences between the actual and the expected issues.
(or exit code 1),
the changes you have made have impacted one or many issues raised by the rules.
Note: if you are facing compilation errors on Windows 10 due to unknown characters, disable beta use unicode utf-8 for worldwide language support
from your Region Settings
.
You can run .\update-expected.ps1
to update the list of expected issues. Please review all added/removed/updated issues to confirm they are wanted. Only after reviewing each difference do the commit.
Note: Integration tests build the code to analyze. If you have an antivirus program on your computer, this may fail with some error messages about an executable file that cannot be open for writing. If this happens, look at the antivirus logs for confirmation, and contact IT team to add an rule to your antivirus program...
You can visualize the differences using:
cd actual
git diff --cached
If you run the project ReviewDiffs
in debug mode, it will print in the output windows all places where a difference has been found. From there you can easily navigate between differences (double-click, F4...).
Disclaimer: This program is still very new and the paint is still very wet. It may not work in all situations, but it's easy to update it ??.
PS: This program outputs message in a way that is compatible with the VsColorOutput extension, so that errors are colored in red, and differences are colored like warnings.
If you want to debug the analysis of a project, you can add a Debugger.Launch()
breakpoint in the class you want to debug. Rebuild SonarAnalyzer.sln
and link the analyzer debug binaries to the project you want to debug the analysis for.
- If you are analyzing the project with the Scanner for .NET, after the begin step you can replace the binaries in the local cache (
%TEMP%\.sonarqube\resources\
- the0
folder for the C# Analyzer, the1
folder for the VB .NET analyzer), and then run the build. - If you don't want to use the Scanner for .NET, you can manually reference the binaries in
analyzers/packaging/binaries/
in the {cs,vb}proj file with<Analyzer Include=... />
items (see SonarAnalyzer.Testing.ImportBefore.targets as an example)
Please note that if the rule is not in SonarWay, you will also need to enable it in a RuleSet file and link it in the {cs,vb}proj file with the <CodeAnalysisRuleSet>
property (see example).
This also works with the Java ITs, as long as the debug assemblies are in the folder which is used by the Java ITs.
When running the build and doing the Roslyn analysis, when hitting the Debugger.Launch()
line, a UI window will prompt you to choose a debugger, where your IDE should show up - you will be able to open the solution and debug.
After the debug session, remove the Debugger.Launch()
line.
Please see the How to contribute section for details on contributing changes back to the code.