Conflicting SonarLint.xml in submodule

Please provide

  • Operating system: Microsoft Windows [Version 10.0.19044.2846]
  • SonarLint plugin version:
  • Programming language you’re coding in: C#
  • Is connected mode used:
    • Connected to SonarCloud

And a thorough description of the problem / question:
I have two repositories A and B. B is linked to A as a git submodule. Both repositories have a CI pipeline where a sonarcloud analysis is computed. We therefore have two different SonarCloud projects for A and B.
To use SonarLint in connected mode, I tried to check in the changes introduced by the SonarLint plugin (.sonarlint directory & insertions in *.csproj files).
This works well the submodule (project B), but whenever I try to create the binding for project A, it says:

  • “A conflicting version of SonarLint.xml has been found. Please delete the file ‘[REDACTED]\A\B.sonarlint\B\CSharp\SonarLint.xml’ and remove references to it from your projects, then re-open the solution and try again…”

I have tried

  1. Just binding project A. Does not help since changes to csproj files in B have to be made that are specific to project A. But project B is also used in other project.
  2. Trying to exclude source files in the complete B directory. (no effect).

Anyone has experience in setting up SonarLint in a git-submodule context? Thank you!

1 Like

@mathias_vetsch welcome to the community.

SonarLint for Visual Studio currently makes a strong assumption that all projects in a solution are mapped to a single Sonar project.

You might be able to get past the binding warning by adding some conditions in your project files so that only one of the SonarLint.xml files is imported (this wiki page gives some more information about what settings are written to the project file and gives some pointers on how you can customise them).

One option might be to add a conditional property like the following to the MSBuild projects in repo B:

  <SonarQubeExclude Condition="  $(SolutionName) == '{name of solution for repo A}'  ">true</SonarQubeExclude>

That might allow you to bind solution A at the same time. However, some features would not work as expected, for example suppressions. SonarLint will be bound to project A and use the list suppressions from A to decide which locally-detected issues to suppress, even when looking at files belonging repo/solution/Sonar project B.

FYI we are currently working on changing how Connected Mode configuration settings are stored. The goal is to not write anything in the project file, and not to add any files to source control. We aim to ship this feature in June (2023). The way the settings are going to be stored should mean that project A will bind without complaining about a conflicting SonarLint.xml. However, the second problem affecting suppressions will remain.


Thanks a lot for your answer, I am very happy to hear that the SonarLint configuration won’t be part of source control after the June release! I won’t put any more effort into it and just wait for the next release.

I am not too concerned about the suppressions in my project, but I’ll see once it is configured.

1 Like

Hi Duncan. We are currently running into this same issue. Excluding the project doesn’t really help since it’s not checked if that’s the solution you’re working on.

Any update on when the extension update will be out? It’s now July and I’m still seeing this same issue.


Hi @jestrmn7. v7.0 has just been released and is available in the VS marketplace.

Please note that migrating Connected Mode settings to the new format involves changing files that are likely to be under source control (this is one-off operation to remove the old binding settings). See the migration guide for more information.

1 Like

Awesome, thanks for the great work!

I just tried it out, enabling connected mode worked well! I see warnings from our customized ruleset only and suppressions are working as well.
For the submodule the plugin is not showing any warnings at all, as you’ve said. A feature to connect submodules independently would be very much appreciated :upside_down_face:

We did not use the migration process, since we didn’t use connected mode before.