Avoiding Resharper <location> web.config Warnings with MVC and WebAPI - asp.net-mvc

Question

ReSharper 7.1.1 code inspection falsely reports <location> elements in a web.config file as being redundant if they concern URLs that do not directly correspond to folders in your source tree. If you're using ASP.NET MVC or Web API, it's normal to have URL paths that don't correspond directly to any particular physical folder.
If you run solution-wide inspection, you get two warnings, and I've been able to disable one of them, but I can't work out how to disable the second.
The first is the "Redundant location element" warning. ReSharper fades out the entire location section. Here's an example of something it'll fade out:
<location path="FederationMetadata">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
You need this configuration if you're using federated login via ACS, and you want to offer a metadata endpoint for that. But there will be no corresponding path of this name.
(Strictly speaking this particular has nothing to do with MVC or Web API. I gave this example because it's quite a common one. However, my project also has several <location> elements corresponding to paths handled through MVC and Web API routing configuration, and they have the same problem. The root cause seems to be the same: ReSharper can't see anything corresponding to this location in the project, so it concludes, incorrectly, that it's wrong. It afflicts MVC and Web API controllers, and also any paths that are available due to things like modules.)
It's easy enough to get rid of this first warning: you can turn it off in the Inspection Severity settings.
Then you end up with a second warning: "Location element is unused: no project item found at FederationMetadata" (and similar warnings for each of the controllers that have corresponding <location> elements).
This one only appears in the "Inspection Results" panel that appears when you inspect the entire solution. None of the usual inspection widgets appear when you look in the source file itself. And weirdly, this one doesn't seem to have an option to be disabled.
I know you can right-click and select "Hide..." (although that appears to think this is a "Redundant location" issue, the one I've already disabled in the settings), but as far as I can tell, hiding inspection results is local to my machine. I want to configure the team shared dotsettings so that it doesn't show this warning anywhere.
I'm aiming for clean inspection results for all users without making each user hide results. Resharper is reporting this issue spuriously - the web.config is fine, it's just that R# has misunderstood it. Does anyone know how I can make this second warning go away? (Or, better, is there some way I can empower R# to be able to know that these 'hidden' locations really do exist?)

Answer 1

I just added this:
<!-- ReSharper disable WebConfig.RedundantLocationTag -->
<!-- ReSharper disable WebConfig.WebConfigPathWarning -->
<location path="api">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<!-- ReSharper restore WebConfig.RedundantLocationTag -->
<!-- ReSharper restore WebConfig.WebConfigPathWarning -->

Answer 2

You can change the R# settings so that they are not local to your machine.
In VS, click the RESHARPER menu, then click Manage Options...
Double click the team-shared item (should be the middle one, between This computer and personal).
By changing settings here, it will create a [ProjectName].csproj.DotSettings file in your project. If you check this file into source control, the settings will be shared with other R# users who develop on the project. AFAIK, any setting you can change (for example telling R# that an inspection severity should be different than the default), you should be able to add to the team-shared settings.
As for your web.config error, I have an even bigger beef with R# because when it is enabled, I lose intellisense on web.config and app.config files. You may be able to tell R# to ignore the error with the following, though I'm not sure it is the solution you are looking for because it will ignore all R# issues with the web.config file.
After double-clicking to edit your team-shared settings (described above), click the Settings item under Code Inspection on the left menu.
Click the Edit Items to Skip button.
Under Files and folders to skip when analysing, click Add File....
Navigate to your web.config file and add it.
This tells R# to ignore the entire web.config file when analysing. Again, not sure if this is the solution you want, but it may work to suppress the false suggestions you are seeing.
Update (reply to comments)
You can in fact change the inspection options from the VS context menu. When the Inspection Options dialog comes up with the radio buttons (Do not show - Error), there is a Save To button. Click that to save the settings to your team-shared DotSettings.

Answer 3

It seems that there are two pieces to this:
Configuring a web path is the best way to deal with both errors
Apparently you have to move the setting out of your DotSettings.user file and into your shared team file by hand
If you click on the offending path attribute (putting the caret in the attribute value) and then wait for the R# popup thing to appear, its menu should offer a way to create a 'path mapping' or to edit the existing mappings for the site. You can use this to tell R# where the actual file corresponding to the path is. Or, since there is no such file in this case, you can just set the action to Ignore for this path.
With that in place, neither of the warnings mentioned will appear.
Unfortunately, the Path mapping dialog is (like the Filter Issues dialog) one of those which only has a "Save" button, and no "Save To" button, offering no control over where the settings will go. In practice, they seem to end up in the <project>.DotSettings.user file for the web project.
But it turns out to work just file if you open that file in a text editor, cut the settings out of there, and paste them into your team-shared solution settings. That appears to get rid of both warnings in a way that should apply to everyone in the project.
(You should be able to use a similar trick for the "Filter Issues" settings, although you need to look in a different place. Those end up in your global settings, but you can use the Manage Options dialog to export those, and then you can open up the exported settings, and copy them into the team-shared solution settings.)