Visual studio - Disable all C++ inspections in a repo/directory or solution


How can we disable sonarlint C++ inspection for a whole repo, for all users?

We use resharper and other Tools for C++, but sonarlint for C#. That means, all developers have the sonarlint extension installed but we do not want double and tripple analysis of all C++ code.

Is there a way to disable them from a repo-root SonarLint.xml or similar? Perhaps we can filter-in only *cs or filter out *.cpp, *.h ?

Anything that is better than per-user settings.json files is of interest. Perhaps something via property pages?

Hi @Johanml.

There isn’t currently a supported way to do this, other than disabling all of the rules in the settings.json file (which I agree would be very tedious).

A hacky approach would be to delete the C++ analyzer subprocess.exe file from the SonarLint VS extension folder. The extension will be installed in a location under %LOCALAPPDATA% like %LOCALAPPDATA%\Microsoft\VisualStudio\15.0_9324960c\Extensions\rym0uprm.rrn\lib. The precise location depends on the version of VS you are using, and will vary from machine to machine as VS randomly names the extension folder.

Deleting the exe will cause SonarLint to produce messages in SonarLint pane of the Output Window, but shouldn’t have any other adverse effects:

Analyzing D:\code\VS2017\S2017CppWindowsProject1\S2017CppWindowsProject1\S2017CppWindowsProject1.cpp
ERROR: Execution failed. The specified executable does not exist: C:\USERS\JOHNDOE\APPDATA\LOCAL\MICROSOFT\VISUALSTUDIO\15.0_9324960C\EXTENSIONS\RYM0UPRM.RRN\lib\subprocess.exe

I’m not a C++ developer so I’ve never looked at the Resharper C++ rules. Is there a large overlap between the Resharper rules and the SonarLint one?

Would you run both analysers if we provided an easy to use mechanism to avoid the duplication? (e.g. some kind of automatic configuration that turned off the overlapping rules)

Hi Dunan. Thanks for the answer.

hacky approach

Since we’re in an enterprise setting with lots of developers I don’t think its viable to manipulate the installation or even user a per user user setting of sonarlint. It has to be configurable via the respective source code directory.

Is there a large overlap between the Resharper rules and the SonarLint one?

There are far too many rules to try to investigate the overlap between sonarlint and other tools. Especially as we maintain the rules per project (in practice: per git repo), not per user.
Resharper contains a huge set of rules just like SonarLint, and it internally bundles clang tidy .

  • clang-tidy has the following mechanism, which is extremely simple and useful:
    “clang-tidy attempts to read configuration for each source file from a
    .clang-tidy file located in the closest parent directory of the source

The clang tidy format also supports basic glob-like patterns, such as

Checks:          '
  • the editorconfig mechanism is the same, but more powerfull since there are special keywords “root” to control how multiple editorconfig files are handled. Convenient but not important.
    “Visual Studio looks for a file named .editorconfig in the directory of the opened file and in every parent directory. The search ends when it reaches the root filepath, or if an .editorconfig* file with root=true is found.”

  • Resharper does an even more advanced thing with per-solution or directory settings with config levels that can include common parts for similar solutions(all reachable via gui)

For us to continue to use sonarlint for C# at all we would need a way to at least turn it off for C++ completely. If (at some point) more granular ways to configure it’s likely we would use that to enable C++ checks selectively. For example, what about this:

  • if there’s a _sonarlint.json or .sonarlint.json in any parent directory “of the source”, for some reasonable definition of “the source”, like the directory of the checked file or (perhaps easier to implement): the directory of the loaded solution - that file is used instead of any file in %appdata%.

  • in “sonarlint.rules” {} - a mechanism to turn C, C++ off completely by default so that all rules need to be opt-in:

    “cpp:default”: {
    “Level”: “Off”
    “cpp:*”: {
    “Level”: “Off”
    (and the same for c, and perhaps javascript??)

    Since we already have many complaints with the speed of visual studio it would be very beneficial if the C++ analysis is not executed at all when no such rules are active.

For reference:

Hi @duncanp . We are still suffering from this problem. Has there been any development?

Surely it should be possible to disable C++ support or configure it other than generating a per-user %appdata% installed file listing all numbers from 0 to 9999 plus some odd ones like “cpp:EmptyCompoundStatement”, which still does not supress the analysis:

Loaded settings from “C:\Users\johlun\AppData\Roaming\SonarLint for Visual Studio\settings.json”.
Calculating effective rule settings…
Note: the following CFamily rules are not available in SonarLint: cpp:S5536, c:S5536, cpp:S5801, c:S5801, cpp:S5814, c:S5814, cpp:S5815, c:S5815, cpp:S5816, c:S5816, cpp:S5824, c:S5824

file.cpp, analysis time: 9,485s

Hi @Johanml,
I confirm your need is clear to us and we are actively tracking this GitHub ticket. However, it seems we do not have lots of users asking for such functionality, thus it is not (for now) in our priority short list.
Nevertheless, we constantly review our priorities and update them based on different criteria, including number of requests and votes in the Community threads.

In an enterprise setting not being able to configure or disable is a show stopper. It’s common for SonarLint to spend 30 seconds each time a new file is opened in the ide. We have now made our own fork that disables all C++ support (“patch” linked in the ticket). If very few asked to be able to configure or disable C++ linting per project/repository then that probably means they don’t understand that they got it and they will have a confusing mix of conflicting warnings, and they will possibly try to fix them by changing configuration by other means (internal visual studio, resharper etc), because it’s not easy to understand what plugin gives you warning hints in the ide.
It would be better to remove C++ support from the main SonarLint plugin and release it as a separate plugin until it’s possible to configure.