SonarQube requires that the rule database be populated up front, at server start. ReSharper provides a list of possible violation types for their tool via the "/dumpIssuesTypes" argument, and the plugin will populate the SonarQube rule repository using these values (as of the plugin's build). However, as new versions come out, or you add your own ReSharper plugins to generate new IssueTypes, it’s possible that you will have violations in your code that the plugin did not know about when the server started, so cannot import into SonarQube appropriately. When the plugin comes across one of these, it will write a log statement (to the runner’s log) and generate a "Sonar.UnknownIssueType" violation with instructions on how to add the rule information to the 'ReSharper custom rules' property in the Settings UI. After adding that setting and restarting SonarQube, future analysis runs will support those IssueTypes.
Other File Types
While the ReSharper tools support the full .Net stack, including .xaml and other file types, the sonar-dotnet API does not currently support more than one language (C# or VB.net) for a given project. For .xaml and other files, the plugin attempts to report the violations against every file ReSharper reports, but they will show up in SonarQube without source code. Additionally, there are a handful of situations where they may end up attached to the project instead.
You can configure the plugin to only report violations against files that are supported by the dotnet plugins using the 'sonar.resharper.includeAllFiles' property.
# 'true' (default) will report every violation in the ReSharper report # 'false' will report only for violations for supported files sonar.resharper.includeAllFiles=false