IDE diagnostics/codefixes don't work in razor files

[DoctorKrolic]

Version used:
VS 2022 v17.3 Preview 4

To reproduce:

1. Create blazor server app
2. Go to FetchData.razor
3. In OnInitializedAsync method add if (forecasts is object) {}:

protected override async Task OnInitializedAsync()
{
    forecasts = await ForecastService.GetForecastAsync(DateTime.Now);

    if (forecasts is object)
    {
        
    }
}

Expected behavior:
IDE0150 Null check can be simplified & a corresponding codefix

Actual behavior:
No diagnostic even on rebuild

[davidwengier]

We currently only allow specific code fixes, so its not surprising that they don't show up. The diagnostic probably should, but is probably not running on the generated file because it is marked as auto generated. We need some way to tell Roslyn to avoid this behaviour.

[earloc]

Just stumbled upon this while trying to test out my custom analyzer (with codefix) on C#-code within razor files. No diagnostics, no code suggestion popping up.

Any directions on how to enable this for razor? @davidwengier , you mentioned that only "specific code fixes" are allowed, currently - could you point my nose onto where this is implemented?

[davidwengier]

The list of code fixes that will be offered in Razor files is here:
https://github.com/dotnet/razor/blob/main/src/Razor/src/Microsoft.CodeAnalysis.Razor.Workspaces/CodeActions/CSharp/CSharpCodeActionProvider.cs#L23

Diagnostics from analyzers should show up fine though, just report them on the generated file at the right location. There is a chance that the code you're analyzing won't map to the Razor file, in which case the squiggle might be wrong, but the diagnostic should still show up. Sounds like that's not happening for you though, so the first thing to check would be to make sure you opted your analyzer in to seeing generated code. If it is, then probably the next step would be to see if Razor is getting the diagnostics from Roslyn, which would be a breakpoint here:
https://github.com/dotnet/razor/blob/main/src/Razor/src/Microsoft.AspNetCore.Razor.LanguageServer/Diagnostics/DocumentPullDiagnosticsEndpoint.cs#L87

[earloc]

Thx @davidwengier for coming back on this.
Opt-ing in for generated code was the first I tried out, but doesn't seem to work OOTB currently for me. I`ll try to investigate further on this and try to at least get the squiggles working.

But the missing diagnostics itself isn't the only thing I'm worrying about not ending up as intended. The ultimate goal would be a code-fix for the diagnostics, but from what I understand, razor can't just utilize the common infrastructure found for vanilla CSharp / VB.net?

I don't mind digging deepter into LSP to get this running (at least, finally a good reason to dive into this, has been long on my "todo"-list ;)).

Currently just have the feeling, that this might end up in a dead-end. Is supplying a code-fix (maybe through LSP) a possible scenario in razor?

And again, thx for your effort.

[davidwengier]

I`ll try to investigate further on this and try to at least get the squiggles working.

If your analyzer is hit and is reporting diagnostics on locations in the generated Foo.razor.<gibberish>.cs files (the gibberish is actually a hash of the project intermediate output path) then that should be enough for you to be able to kick the can over to us to investigate. Setting up a sample repro project, if one isn't already in your repo, would be appreciated.

from what I understand, razor can't just utilize the common infrastructure found for vanilla CSharp / VB.net?

Long term it is my goal that every Roslyn analyzer and code fix works for C# in Razor files just as it does for C# in C# files. There are a lot of changes that need to happen for us to get there, and we're currently in the process of rearchitecting how the Razor IDE pieces work which is a big step in that direction. There was also a hackathon project done recently around getting Razor specific analyzers working (ie, things that work on the Razor syntax tree, not the generated C#) so that is also a future possibility. Unfortunately, all of this is in the distant future, and we simply have no idea when everything will finally land for your scenario.

Currently just have the feeling, that this might end up in a dead-end

I'm not sure about dead-end, but I think right now it's at best a choice between a very difficult path, or a long wait.

Is supplying a code-fix (maybe through LSP) a possible scenario in razor?

This would be the very difficult path option. The Razor LSP server is not extensible at the moment but, in theory, you could supply your own LSP server for Razor files, and that could report code actions (what code fixes are called in LSP land) and deal with them appropriately. In theory your server would happily sit next to our LSP server, and everything would be sunshine and roses. And then you do it all again for VS Code.

[earloc]

Phew, this seems like quite a journey.

So I checked back in VS and the squiggles appeared where expected. Had to override the diagnostics severity to Warning in .editorconfig, as I intended my code-fix to be just a suggestion.
This didn't work in VSCode, though. Will play around a bit more.

[earloc]

Ok, so I changed the default severity of my diagnostics to Warning:
VS: displays as Warning, can be overriden in .editorconfig
VSCode: displays as Warning, can NOT be overriden in .editorconfig

Can work with that 😉.

But couldn't find an existing issue for this? Is this known behavior? Otherwise, I could submit an issue for this with a repro.

[davidwengier]

So neither display when you report a Suggestion? That sounds like a bug too.

If you can log a new issue for VS Code not honoring .editorconfig, that would be great, and we can leave this for diagnostics not reported for Suggestions. It's entirely possible this was done because there is too much noise from Roslyn reporting suggestions for generated code, but we should at least look into it.

[earloc]

So I played around a bit with my default-severity (Hidden->Warning->Info).
This gets respected in VS as well as VSCode (despite VS showing it in the "problem"-pane, wheras VSCode does not - but the little mini-squiggles DO appear:

VS:

VSCode:

However, when I add
dotnet_diagnostic.TR1000.severity = error to an .editorconfig, this only gets reflected in VS:

TLDR;: VSCode only honors the default-severity of the reported diagnostic, ignoring overrides from .editorconfig.
BUT it honors whatever default-severity is shipped.

Same goes for other diagnostics (let's say to provoke CS8618 and configure it to be an error, instead of a warning:

dotnet_diagnostic.CS8618.severity = error

@code {
    private WeatherForecast[]? forecasts;
    
    [Parameter] public string Foo { get; set; }

    protected override async Task OnInitializedAsync()
    {
        forecasts = await ForecastService.GetForecastAsync(DateTime.Now);
    }
}

VS:

VSCode (still):

I'll file a separate issue in this repo for this, as vanilla *.cs-files reflect the severity from .editorconfig in both VS and VSCode (even for my custom analyzer).

edit: typos

[earloc]

I guess this is already covered by #6967.
@davidwengier let me know, if you still need a separate issue / repro.