Incorrect ReSharper Behavior for CS1591 Warning

After upgrading from Visual Studio 16.8.x to 16.9.x the JetBrains ReSharper suddenly started marking a lot of public identifiers in the code as compiler errors with a message: "Missing XML comment for publicly visible type or member...". You can imagine how that can be very annoying.

So, you opened your code and now there are a lot of red ReSharper marks all over the place that weren't there before. The most annoying part is those marks are not warnings but actual errors. Is that right?

To be sure, let's look at the Visual Studio's Error List panel but there is nothing showing there related to the errors outlined by the ReSharper, so it's definitely a ReSharper's problem.

Upon inspection of ReSharper properties a specific setting responsible for a ReSharper reaction still correctly shows the "warning" level, yet the ReSharper insists that it's an actual error and has to be fixed.

Well, what do we need to do to get rid of this annoying false positive ReSharper's error? First, let's understand why all this is happening. Actually, there are a few reasons for the ReSharper's reaction:

1. The project file .csproj includes a setting to generate an XML documentation file during a compilation. This setting is responsible for a compiler warning CS1591.

2.  However, that setting alone should not have triggered the ReSharper to show an error because it's own level is set to warning. Therefore, there must be something else, and yes, there is: apparently another project setting "Warnings as errors" is set to "All".

Now, these two settings together make ReSharper behave this way and ignore its own "warning" level setting. Obviously, with the Visual Studio upgrade the project settings and the compiler behavior did not change but the ReSharper behavior did. So, you make your conclusions yourself.

Now, what are the options?

One, if we uncheck the ReSharper option "Missing XML comment..." the warning/error will be entirely gone.

The same will happen if we uncheck the "XML documentation file" option in the project properties, and this is another option.

If, however, we want to keep being informed about potential mishandling of the XmlDoc comments, one more option is to just change the "Treat warnings as errors" option in the project properties to either "None" or "Specific" and the ReSharper's error will turn into an expected "warning".

Finally, we've learned how to control the behavior of multiple components to achieve a preferred outcome.