dotnet / razor

Compiler and tooling experience for Razor ASP.NET Core apps in Visual Studio, Visual Studio for Mac, and VS Code.
https://asp.net
MIT License
506 stars 196 forks source link

Suppress RZ10012 #6967

Open lonix1 opened 2 years ago

lonix1 commented 2 years ago

In my blazor project, I get hundreds of RZ10012 warnings:

Found markup element with unexpected name 'Foo'. If this is intended to be a component, add a @using directive for its namespace.(RZ10012)

This seems to be a bug, going back for years. It's been reported dozens of times on SO and in various GitHub repos. There are no fixes or workarounds that work consistently.

It's impossible to be productive when the entire editor shows squigglies. Since the app itself works, I want to suppress that analyser rule.

So I added this to an .editorconfig in the project's root:

[*.razor]
dotnet_diagnostic.RZ10012.severity = none

That doesn't help. I also tried a .globalconfig file.

How can I suppress it?

(I'm using .net6 and vscode)

DustinCampbell commented 2 years ago

@allisonchou: Let's test this with the latest VS Code bits to see if it still repros there.

MihaMarkic commented 2 years ago

It happened to me in Visual Studio 17.4 just today (not VS Code). In my case closing VS, deleting obj and bin directories and opening VS again, worked.

lonix1 commented 2 years ago

For me, the rm -rf ./bin ./obj trick works sometimes, but even so, only for a few builds after which the problem returns. And I need to close and open vscode too.

vgb1993 commented 1 year ago

It happens to me too, it is NOT USABLE AT ALL.

This is a very much urgent issue in my opinion. I simply can not keep coding like this.

Check this screen recording, it starts to blink on and off.

screencast-nimbus-capture-2023.01.13-18_56_58.webm

allisonchou commented 1 year ago

@phil-allen-msft I'm moving this back to triage since users are reporting this repros in both VS and VS Code. The last comment I believe is another instance of the colorization issues we've been seeing recently.

chsienki commented 1 year ago

@phil-allen-msft what was the rationale behind making this a compiler issue? Is there some more info somewhere about what’s causing it?

chsienki commented 1 year ago

Oh, I see this is about the suppression itself not working. Ok makes sense that that would be us.

MrDoe commented 9 months ago

I still have the same issue on .NET 8 using C# and Blazor. Suppressing the RZ10012 warning still doesn't work via .editorconfig or the tag in the .csproj file.

earloc commented 1 month ago

Stumbled upon this as well while tackling some other issue over at https://github.com/dotnet/razor/issues/6641#issuecomment-2447606522

(Note that I did the override in .editorconfig on global (all files), as well as on *.cs and *.razor files (and combinations).

[*]
indent_style = space
dotnet_diagnostic.CS8618.severity = error

[*.razor]
dotnet_diagnostic.CS8618.severity = error

[*.cs]
dotnet_diagnostic.CS8618.severity = error

Override works for *.cs

public class Class1
{
    public string Foo { get; set; }
}

✔️ VS: Image

✔️ VSCode: Image

But not for *.razor, at least in VSCode...

✔️ VS: Image

❌ VSCode (still): Image

So generally speaking, *.razor-files do not respect severity overrides from an .editorconfig-file (even regardless, if the .editorconfig specifies root = true.

edits: more details

davidwengier commented 1 month ago

I think that .editorconfig not working when tweaking CS* diagnostics, when they're defined for *.cs files, for code in *.razor files is a Roslyn issue, but I could be wrong.

earloc commented 1 month ago

putting the override in a .globalconfig indeed let's VSCode honor the modified severity. I guess this is due to the fact that .editorconfig-settings only applies to non-generated code beneath the current project-path (and C# wihtihn *.razor is treated as generated code? since ) , whereas .globalconfig applies to all artifacts (let it be generated or non-generated content).

This might be due to the original confusion about .editorconfig vs .globalconfig and somehow is treated differntly accross VS and VSCode. But at least there would be a workaround to adress OPs problem (at least on .net 8).