The ReSharper inspectcode tool runs in two phases:
- "Analyzing" - during this phase it parses all of the files, building an abstract syntax tree of all of the supported files in the solution
- "Inspecting" - using the AST build during analysis phase, determine any violations
While I believe the inspection phase can be modified using the built-in ReSharper options tooling as you mentioned, those files are still analysed, at least in part, in order to build a full AST.
There are some key notes here:
- ReSharper does a VERY deep analysis of the source code, which makes it a very powerful (and popular) tool.
- ReSharper analyses far more file types than SonarQube. For example, .xaml (HTML-style mark-up with runtime bindings to native .NET objects) are analysed to determine if the properties/fields named in the .xaml actually exist in the objects to which they are late-bound.
- ReSharper has a multi-level configuration system – where each layer can inherit and/or override the layer beneath it, and the number of layers themselves can be modified. Typically, this looks like this:
- machine layer (a global settings file for the machine)
- "Team" solution file (a shared team-level file for this VS solution, typically committed into source control with the .sln file)
- "User" solution file (a user-specific file, for this VS solution)
So there are a few use cases to consider, which I have not fully flushed out yet (thus have not implemented in the plugin yet), but I believe I will be able to create a "User" level options file in order to ignore the file patterns used in the SonarQube ignore settings. However, there is a risk I would override or cause the tool to ignore the "Team" level settings, which would be a very bad thing.
Additionally, many users (especially me) will want to report violations against files which the .Net plugins don't formally support. For example, I want to know when the .xaml files are bound to properties that don't actually exist, thus could cause a runtime exception. And at this point, I'm not sure how to differentiate between files that are "ignored" and files that are "not supported" in the .NET plugins. So I suspect I will just have an all-or-none property so users can pick.
Ultimately, the guidance I would give to any user is to use ReSharper's UI in Visual Studio to configure the scope of the analysis and save that as a "Team" setting, then run the analysis outside of the sonar runner and utilize the reuseReports run mode. For solutions of any complexity, this will be the most reliable path, as well as the quickest to run.
Date: Mon, 18 Nov 2013 14:36:57 -0500
Subject: Re: [sonar-user] Call for beta users - .Net ReSharper plugin
My second ReSharper-on-board analysis is still running (the first one timed-out), and I understand now why you put so much emphasis on how the analysis is run. It's taking much longer than usual (but then you knew that.)
What strikes me is that it appears to be examining every file in the project - including ones I'm pretty sure weren't imported by SonarQube & therefore ones I'm pretty sure there's no point in analyzing.
So... I'm wondering if you can control the scope of the analysis. I'm completely new to this tool, but it looks like you can set analysis exclusions using a file mask and then import those settings from a url. At least, it looks possible for the GUI version....
This error will occur when a file is ignored by the .NET plugin by default (generated code, unsupported type, etc) but a plugin (the ReSharper plugin, in this case) creates violations against the file.
I need to add a property to the plugin to enable/disable submitting violations for ignored files. This also ties into your other email (which I have yet to respond to) about having R# ignore files as well.
Date: Wed, 20 Nov 2013 10:56:42 -0500
Subject: [sonar-user] ReSharper beta - odd analysis log messages
I was just looking back through the analysis log of my ReSharper analysis. What do these warnings mean?
I don't see them on other projects & I didn't see them on the analysis of this project where ReSharper didn't kick in...