[BUG] Opening a solution with C# Dev Kit causes dotnet build to ignore .editorconfig analyzer settings

[DavidZidar]

Describe the Issue

I have multiple projects that build cleanly with no warnings using dotnet build at the CLI.

But after having opened them using Visual Studio Code with the C# Dev Kit extension dotnet build shows warnings that are clearly disabled in the .editorconfig file. Even after exiting Visual Studio Code I have to kill all dotnet.exe processes to make dotnet build build properly again.

Steps To Reproduce

1. Disable some analyzer warning in .editorconfig, for example dotnet_diagnostic.CA1040.severity = none
2. Open the solution using C# Dev Kit and watch it run restore
3. Build using dotnet build at the CLI

Expected Behavior

Disabled warnings should not be displayed by dotnet build.

Environment Information

• OS: Windows 11
• VS Code Version: 1.79.2
• Extension Version: v0.1.103

Workaround

Set the environment variable MSBUILDDISABLENODEREUSE=1, this does makes builds slower but they'll be correct.

[DavidZidar]

My suspicion is that there is something wrong with the way C# Dev Kit runs restore. On a side note, it would be nice to be able to disable this forced restore entirely. Opening a project that isn't already restored is a rare edge case in my regular workflow.

[DavidZidar]

On second thought, it might not be the restore that's causing the issue, I am able to build cleanly using dotnet build --no-restore after killing all dotnet.exe-processes. It seems that dotnet build is communicating with the already running processes started by C# Dev Kit and somehow gets incorrect analyzers settings.

[DavidZidar]

Running dotnet build /nodeReuse:false is building cleanly every time even after a regular call to dotnet build has started showing warnings.

[DavidZidar]

As a temporary workaround I have set the environment variable MSBUILDDISABLENODEREUSE=1 which makes everything slower but at least it works as it should.

[mdsitton]

This is causing issues for our team, and needs to be resolved as soon as is reasonable. Thanks!

[richardstanton]

Hello, I have been attempting to create a repro of this problem but have been unable to recreate it. I was able to make a simple console app with a suppressed warning (CA2014) and opened it in VSCode with C# DevKit v0.5.150. I see the extension launch dotnet/msbuild processes with node reuse on. I then attempt a command line build of dotnet build -nodeReuse:true --no-incremental. Using that it seemed like the msbuild nodes are resused, but the build successfully used the .editorconfig to ignore the warning.

This seems like it might be a bug in core msbuild, so I will reach out to their team to see if this sounds like any known issues. However, I would still like to create a repro. I suspect there is still some difference I'm missing. What version of .NET SDK are you using? Can you describe the layout of the directory structure (like where the .editorconfig is relative to the workspace and solution). Is there anything else in the dev environment that might impact this repro? Thank you!

I am also working to add a diagnostic in a future preview build of the C# DevKit extension that will allow turning off node reuse, that may be a better workaround or at least help identify that this is the root cause of the bug.

[DavidZidar]

@richardstanton Thanks for looking into this, but it's been several months and several .NET SDK releases later. I was running all the latest bits at the time, so probably .NET SDK 7.0.7.

However, at the moment I am also unable to reproduce this issue. Maybe the issue has been solved in MSBuild or C# Dev Kit already?

Unfortunately I have been using the MSBUILDDISABLENODEREUSE=1 flag ever since I reported this issue to be able to work so I have no idea when the issue disappeared.

To answer your questions my directory structure looks like this:

.git/
src/Project1/Project1.csproj
src/Project2/Project2.csproj
.editorconfig
solution.sln

[richardstanton]

Since we don't have a repro anymore, I'm going to resolve this bug. It seems like it has been fixed by other updates.

[olstakh]

@DavidZidar so which version did the issue disappear in (or which version you're currently using that doesn't repro)? I'm still facing this issue, may be i need to update something

[DavidZidar]

@olstakh Interesting, I tried using .NET SDK 7.0.12 and 8.0.0-rc.2.23479.10 and I have the C# extension v2.6.24 and C# Dev Kit v0.5.150 and wasn't able to replicate the issue just before the weekend.

[olstakh]

@DavidZidar It is interesting indeed. I have 2 environments with the same MSBuild version (17.3.2+561848881), .net SDK (6.0.415 and 7.0.402), c# extension 2.6.24 and c# dev kit extension 0.5.150. I can repro this issue on only one of those 2 environments (used to be able to repro on both about 2 weeks ago)

[DavidZidar]

@olstakh That does make it sound like the problem is in the .NET SDK itself considering that everything else is the same on your machine.

[olstakh]

@DavidZidar i mean installed SDKs are same also, like i mentioned.. something is afoot here that im missing