dotnet / dotnet/sdk

dotnet format CS8618 where NUnit3002 applies

Open
#50,978 1 comment 1 reaction 0 assignees View on GitHub
Area-Format untriaged
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.