dotnet format CS8618 where NUnit3002 applies
- Dominant language
- C#
- Stars
- 3.2k
- Forks
- 1.3k
- PR merge metrics
- PR metrics pending
Description
### Describe the bug
`dotnet format` is fixing CS8618 inside NUnit TestFixtures where that complaint is suppressed by [NUnit3002](https://docs.nunit.org/articles/nunit-analyzers/NUnit3002.html). I would not expect it to fix something which is not a complaint.
### To Reproduce
Create a solution with a C# code DLL project and an NUnit test project. Add the `NUnit.Analyzers` package to the test project, and add a project reference from the Test project to the code project.
I have a `global.json` file alongside the solution to pin to SDK 8.0
```
{
"sdk": {
"version": "8.0.0",
"rollForward": "minor"
}
}
```
In the code project add this class:
```
internal sealed class NameCleaner
{
private NameCleaner _decorated;
public void Example()
{
_decorated = new NameCleaner();
}
}
```
in the test project add this class
```
using NUnit.Framework;
[TestFixture]
public class NameCleanerTests
{
private NameCleaner _sut;
[SetUp]
public void SetUp()
{
_sut = new NameCleaner();
}
[Test]
public void Placeholder()
{
Assert.Pass();
}
}
```
Notice how these are both classes, each with a non-nullable field which is not initialised by the constructor, but by a method. The code class correctly highlights the CS8618 in the Visual Studio IDE with a squiggle, and when compiling, and would need fixing by (for example) making the field nullable.
By comparison, the field in the TestFixture does not receive CS8618, because it is suppressed by NUnit3002. this can be proven by temporarily commenting out the `[SetUp]` attribute line - ensure you leave it uncommented.
Now run `dotnet format` on the solution. It "fixes" both the code and the test (on my machine, it adds a `?` to the field's type; on a GitHub build server, it's changing the field to be `required` - I haven't pinned down exactly why there is a difference, I'm assuming it's using a different version of the SDK or something).
This definitely relates to the CS8618 complaint because if you create a `.editorconfig` file alongside the solution and add these lines to it:
```
[*.cs]
dotnet_diagnostic.CS8618.severity = none
```
Then this prevents the files being fixed. And my work-around for now is to change the section to be `[*Tests.cs]` so that it only suppresses CS8618 in test fixtures, which will work for me, but maybe not everyone names their test fixtures that way.
### Exceptions (if any)
n/a
### Further technical details
details of dotnet --info
- The IDE (VS / VS Code/ VS4Mac) you're running on, and its version: Microsoft Visual Studio Professional 2022 (64-bit) - Current Version 17.14.16
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.