2019.2.0 Showing new and incorrect warnings in several cases

[softworkz]

After upgrading I'm suddenly seeing inspection warnings that haven't existed before.

Examples:

• adding parentheses for non-obvious references
• Blank lines are redundant
• Constructor 'xx' is never used, even though it's decorated with [UsedImplicitly]
• Expression is always null

When the StyleCop plugin is active, those are always showing up as warnings. It's impossible to control them via any kind of ReSharper settings.

When I choose "Disable StyleCop support" via the icon in the VS status bar, those warnings behave as configured in the ReSharper settings (and disappear when configured to do so).

But with the StyleCop plugin active, there is no way to disable those from showing as warnings.

This is a severe regression from the previous version (2019.1).

Previously all our code files "were green". Now it is no longer possible to determine the required adjustments to achieve code style compliance.

I'm not quite sure though, whether this is a bug in ReSharper or in this StyleCop plugin..?

[matkoch]

Could you create a repro? Especially the Constructor is never used is really weird, since it doesn't have to do anything with StyleCop.

[softworkz]

I assume it should be trivial to reproduce:

Should it turn out that it doesn't reproduce on your side, I'll set up a repro solution of course...

[matkoch]

The warning shown in the picture is not a StyleCop warning.

[softworkz]

I know.

But it does show up when the StyleCop plugin is active, even though it's disabled in ReSharper. When it's disabled in ReSharper it disappears when disabling the StyleCop plugin.

[softworkz]

Or in other words: When the StyleCop plugin is active, ReSharper is showing certain ReSharper-Warnings even though they are disabled in ReSharper.

[matkoch]

I couldn't reproduce it yet. By the way, what icon in the status bar do you mean? And what StyleCop related NuGet packages do you reference?

[softworkz]

That's the icon I'm referring to:

All projects are referencing StyleCop.Analyzers 1.1.118 (and nothing else)

ReSharper options for the StyleCop plugin:

The problem exists with VS 2017 as well as VS 2019. It didn't exist before upgrading to ReSharper 2019.2.

[matkoch]

StyleCop analyzers is different to StyleCop. It's a separate implementation. Basically, you shouldn't install StyleCop.ReSharper if you're not using the StyleCop package with its StyleCop.Settings file.

[matkoch]

Can you please verify that this is definitely caused by the extension? The Disable StyleCop support action doesn't relate to the plugin. See here for more information. So please uninstall the extension, and then try to reproduce.

[softworkz]

StyleCop analyzers is different to StyleCop. It's a separate implementation. Basically, you shouldn't install StyleCop.ReSharper if you're not using the StyleCop package with its StyleCop.Settings file.

Our previous experience was that even with StyleCop.Analyzers it was required to have the StyleCop plugin installed to ensure that ReSharper is adopting all StyleCop rules.

Now I've uninstalled the plugin and I can confirm that the problem still occurs in the same way as before.

The undesired warnings disappear after unchecking the setting below:

But obviously that's not what we want. We want ReSharper to inspect code based on StyleCop rules just like before.

At least it appears that it's not caused by a bug in the plugin. I'm not sure about your kind of relation with JetBrains, hence the question: Should I create a support case with JetBrains directly?

[matkoch]

It would be best to create a new issue on https://youtrack.jetbrains.com. Maybe describe the issue once more, since we've got already a few findings here. Post me the issue number, and I can assign it to the proper person.

On another note, in 2019.2 the setting Read settings from editorconfig and project settings is enabled by default. That could also interfer. Also, functionality of SC and SCA overlaps quite a bit. Afaik, when the option Read code style from Settings.StyleCop files is enabled, and the file is not there, it will assume the defaults.

[matkoch]

One more conclusion I missed to draw: the fact that SC and SCA overlap is also the reason why you've perceived that the StyleCop.ReSharper plugin is necessary for ReSharper to work with StyleCop. Actually, there's no support for SCA.

[softworkz]

This is all a gigantic mess. There are things thrown into the ring from all sides (ReSharper, editorconfig, Visual Studio features, clang, autodetect-from-existing-code), most of them covering only a fraction, none of them working together in a reasonable way. It's a nightmare IMO.

Probably our best option is to drop SCA and revert to classic StyleCop with the ReSharper plugin? (problems in classic SC made us turn to SCA, but it seems that this is less evil than everything else)

[matkoch]

Personally, I'm not really a fan of StyleCop (neither of StyleCopAnalyzers). The original StyleCop tends to be a bit late with new language features, and it adds the penalty of another parsing step. For SCA, there currently is no mapping between their settings and ReSharpers (= also painful). Since 2018.1, ReSharper and Rider have their own formatting inspections, which are good enough for my cases. What's missing is mostly the part about documentation. A while ago, I also described a workflow for a zero-warning policy, which I think could be interesting for you.

[softworkz]

The article is interesting, but we're using TFS and not every developer has R#. No matter whether supported or not - the combination of SCA + R# StyleCop plugin has worked quite well until 2019.2. I will create a ticket and post back the id. Hopefully this problem can be solved in R#.

[matkoch]

ReSharper inspections can be used on CI independently of having ReSharper, just in case you didn't know. Otherwise 👍

[tinuroth]

Not that this helps much, but just to let you know that we were affected by the same unclear, sometimes huge number of false positives in exactly the same situation as above, the errors showing in Rider for us. Not everyone saw the same, though. A mix of opening the solution in VS, running a solution wide analysis there, and going back to Rider, switching branches, ... eventually made the problem disappear magically... so, my suspicion is that the problem is due to some VS/R# vs. Rider configuration/caching cross-talk. Does not help much, I know, but for me the problem is suddenly gone.