SL-generated ruleset refers to absolute path when importing rules from NuGet

Using SonarLint for Visual Studio 2019.

We import our ruleset by adding a NuGet package. When adding SonarLint this ruleset is referred to directly where it is downloaded in the user home folder (.nuget subfolder structure). This means that we either need to change how we distribute our coding standards (ruleset) or each time someone opens the project the project ruleset is (supposedly) changed. It also means that people who don’t use SonarLint have every linting rule under the sun enabled.

Neither of these options are workable.

The project ruleset create by SonarLint looks like this (Company removed):

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="SonarQube - SonarLintExample [..]" ToolsVersion="16.0">
  <Include Path="..\.sonarlint\devopstest_[..]_sonarlintcsharp.ruleset" Action="Default" />
  <Include Path="c:\users\Mark\.nuget\packages\[..].developmentstandards.csharp\\build\\..\ruleset\stylecop.analyzers.extensions.ruleset" Action="Default" />

Hello @Gjoel - welcome to the community.

I’m assuming you are using Connected Mode, and that you are talking about the format of the per-project ruleset file that is generated by SonarLint by default.

Distributing rulesets via a NuGet package is an interesting approach that we haven’t come across before.

The flexibility of MSBuild means there is a huge variety of ways in which projects can be configured.
The default SL binding behaviour is designed to work in the majority of possible configurations. However, the method it uses is verbose (e.g. adding a ruleset to every project), and there will be cases in which it doesn’t work.

Fortunately, the default configuration is just that. You are free to change it using any mechanism supported by MSBuild. SonarLint won’t complain as long as the generated Sonar C#/VB.NET ruleset is referenced somehow. For example, you can just edit the generated ruleset file.
See this wiki page for more information.

(cc @Marco_Comi for info)