Analyzer message NUnit2005 is indeed extremely annoying about nunit HOT 4 CLOSED

If you want to use the Assert.AreEqual that is up to you.

Note that NUnit2005 would also fire for NUnit v3 and has done so for years.

Disabling NUnit2005 :

As mentioned in #4401, if you don't like what the analyzer suggests, remove it.

If you only don't like this one rule, disable it.
There is microsoft documentation for these, but in summary, there are 2 options:

1. Add a single .editorconfig in the root directory of all your projects containing:

root = true

[*.cs]

# NUnit2005: Consider using Assert.That(actual, Is.EqualTo(expected)) instead of ClassicAssert.AreEqual(expected, actual)
dotnet_diagnostic.NUnit2005.severity = none

2. Create a "DisableNUnit2005.globalconfig" file containing:

is_global = true 

# NUnit2005: Consider using Assert.That(actual, Is.EqualTo(expected)) instead of ClassicAssert.AreEqual(expected, actual)
dotnet_diagnostic.NUnit2005.severity = none

and reference it in your Directory.Build.props file for your solution like in:

<ItemGroup>
    <GlobalAnalyzerConfigFiles Include="$(MSBuildThisFileDirectory)/DisableNUnit2005.globalconfig"" />
</ItemGroup>

I don't want to write a custom .editorconfig files and commit them. This sucks. There's a reason those files don't belong in a repo. Everybody has a different .editorconfig locally!

I disagree here, they DO belong in a repo. It ensures consistent rules and style for everybody using the repo.
You want to disable the NUnit2005 for everybody using your project not just you isn't it?
For my work, we use one .editorconfig in a repo containing 500+ projects shared with 60+ developers.
If each of them used a different coding style and other rules it would be a mess.

If you are talking about it not compiling that is another issue.

However, to make them compile with NUnit 4 you needs to add something to your solution only once in the root directory:
See the migration guide

from nunit.

Fix this shit. Like, seriously. Fix this. Please, guys. This is stupid.
There has to be a better way of solving this, than just saying "shut up, screw you, Imma close this thing as a duplicate".

and

And this joke of a doc says

You may be as angry as you like, but taking it out on us this way, using language, is no acceptable behavior. Please see https://dotnetfoundation.org/about/policies/code-of-conduct . See the note at the end of this issue, saying "Remember, contributions to this repository should follow its contributing guidelines and code of conduct.". This also applies to issues you raise.

We are doing this work on a voluntary non-paid basis, and we are not into this to be called "stupid", "shit" and "joke".

To address some of your items:

We have written migration documentation to the best of our abilities, which also includes ways to avoid what you write above about how to continue using the classic asserts using only Assert, see this section for a couple of suggestions.

This fixes your point 1 and 2 above.

Point 3, not sure why you would need a ruleset.

Point 4: It actually is common to include an .editorconfig committed to the repo. That would constitute how your team would like to handle the code in the projects, so it is not a bad idea, imho. Having only locals of this file would easily cause files to change between commits from different developers, and could be seen as annoying.

Point 5. Agree, I would not recommend using pragmas on anything but special cases.

Point 6. Execpt for the "joke" comment, I agree that this is equal to point 5, only for special cases.

So to solve you issue with the analyzer, and given you still dont want to add suppressions to .editorconfig, you can add the suppressions a global suppressions file named GlobalSuppressions.cs.

Alternatively, skip installing the analyzer package altogether.

Staying on the version 3.X IS a valid option. As said in other responses, we will maintain that series and backport changes as far as we are able to - in our free time.

PS: Noted @manfred-brands also answered this at the same time.

from nunit.

if you don't like what the analyzer suggests, remove it.

Thanks, this is just what I need.

Note that NUnit2005 would also fire for NUnit v3 and has done so for years.

Well, this beast of a solution is using some pretty outdated libraries. Has been using till now.

You may be as angry as you like

Nah nah sorry man, I'm no angry. Adding some emotion to it is just a way to get someone to react. I mean, take a look at this poor soul - the wrote a polite ticket in accordance to all codes and conducts and got ignored for 2 years.

Thanks for the migration doc. Somehow google searches didn't show that one, but instead pointed to this weird doc. I wonder if one could just add the-migration-link there.

from nunit.

To anybody from the future who comes in here and sees this, the easiest option to make it disappear is to just stick the following into your .csproj:

<PropertyGroup><NoWarn>NUnit2005</NoWarn></PropertyGroup>

from nunit.