[BUG] Blazor Components are seen a unknown

[DevTard]

Describe the Issue

When using the extension to program a Blazor project any custom components are not identified and are underlined as a warning

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

This is for components that are referenced via usings and was not an issue prior to installing this extension.

Steps To Reproduce

No response

Expected Behavior

No response

Environment Information

• OS - MacOS
• VSCODE - 1.78.2 (Universal)
• Extension
  • C# - v2.0.206
  • C# Dev Kit - v0.1.83
  • IntelliCode for C# Dev Kit - v0.1.9

[phil-allen-msft]

@DevTard , we recently released an update to the C# and C# Dev Kit extensions. From your description of the behavior, it's possible that a solution which includes the projects that have your components is not open. In your particular case, do you have a *.sln file in your open folder? Do you have more than one?

[artyomszasa]

Installing C# Dev kit completly breaks all blazor projects for me (even the simpliest ones).

Solution is open, yet not a single blazor tag is recognized at all.

Uninstalling C# dev kit extension does not resolve this issue, downgrading the Omnisharp extension back to "release version" does. Issue is reproducible even without C# dev kit extension --> switching Omnisharp to "pre-release" version instantly breaks all razor files, switching back fixes that...

[ryzngard]

Installing C# Dev kit completly breaks all blazor projects for me (even the simpliest ones).

Solution is open, yet not a single blazor tag is recognized at all.

Uninstalling C# dev kit extension does not resolve this issue, downgrading the Omnisharp extension back to "release version" does. Issue is reproducible even without C# dev kit extension --> switching Omnisharp to "pre-release" version instantly breaks all razor files, switching back fixes that...

I'm sorry to hear that. Unfortunately I was unable to reproduce this issue with

C# v2.0.376
DevKit v0.4.5

If you are still hitting this issue can you please provide a copy of the logs for Razor Logs. Similar to instructions about reporting an issue https://github.com/dotnet/vscode-csharp#found-a-bug

[stefffdev]

The problem seems to still exist, happened right now with the C# and DevKit Versions you mentioned.
Razor Logs are attached.
Razor.log

[ryzngard]

The problem seems to still exist, happened right now with the C# and DevKit Versions you mentioned. Razor Logs are attached. Razor.log

Thanks for providing logs. We're still unable to find a repro on M1 Mac with versions tested. If possible, do you have a repro project for this?

[stefffdev]

I think I was able to create a small project to reproduce the issue but I would rather not make it public, can I email it instead?

[ryzngard]

Yup! Just send it to [email protected]

[garrettlondon1]

Same on my project, the Button component is even open in the tab above

[mikes-gh]

I have this issue.
I am one of the maintainers of https://github.com/MudBlazor/MudBlazor however I am the only vscode mac user.
If you open this project in vscode you will get thousands of RZ10012.
This didn't happen when I was using omnisharp.

Generally I find the code analysis completely broken on the MudBlazor project for me.

[mikes-gh]

It seems to me that RZ10012 is shown for components in a referenced Blazor component library that don't have a code behind file. Components with a code behind are resolved. Devkit seems to have a problem discovering components without a code behind.

[garrettlondon1]

For me as well, Visual Studio & VS Code experience is broken in latest versions with RZ10012 errors everywhere..

[mikes-gh]

@jaredpar could this be related to dotnet/razor#8718? Is it possible C# Devkit is using an old version of the razor compiler for its design time compilation? Without the code there's no way for us to tell.

[ryzngard]

dotnet/razor#9600 may be related as well, if you're updating to .NET 8 (or have changed targeting in some other way)

[joe-mills]

@ryzngard thanks for the update. transparency is key when we have a critical mass of very frustrating issues that seem to be going unanswered.

I also appreciate the explanation but I'm still not clear if we should expect to be able to develop Blazor on vscode at all.

If I follow the latest docs from MS for starting a Blazor Server project in VS code it gives you step by step instructions using c# Dev Kit and you end up with broken intelligence and tooling (dotnet -- version 8.0.302)

https://learn.microsoft.com/en-us/aspnet/core/blazor/tooling?view=aspnetcore-8.0&pivots=vsc

[garrettlondon1]

We just need to find a way to slap AI on this and then it will get prioritized :)

[joe-mills]

We just need to find a way to slap AI on this and then it will get prioritized :)

Maybe it works on the new copilot pc's. I think they do AI.. ;)

[marcos-prins]

We just need to find a way to slap AI on this and then it will get prioritized :)

I was thinking exactly the same, because it looks like AI is the only one priority for Microsoft right now

[carlsixsmith-moj]

The dev kit has definitely made the experience of coding in VS Code a lot worse. While you can develop blazor apps, there's so much noise from non-errors that it's a waste of time. Also enabling the C# Dev Kit brings VS Code performance down to the same poor level as Visual Studio, kind of defeats the point of having it.

Have to stick to JetBrains Rider, which has it's own issues (mainly around support at release time). Thankfully it's cross platform so I can use it on my mac, windows and linux machines.

[afallingstone]

It sucks because this has been broken for a while... But, here is a work around that seems to work for me.

1. After opening the solution. Add a blank _Imports.razor inside a folder (not root). Wait till the tab at the top turns green, then delete it.
2. Open any components referenced in the razor file you want to work in and view them until they are fully loaded.
3. Re-open the razor file you want to work in, and the component references should work until you restart VS Code, then you have to do this again.
4. This works for both .razor and .cs files.

Here is an example:

Before

After

[ryzngard]

@afallingstone hopefully we've found a fix for this with a recent merge dotnet/vscode-csharp#7273

It's expected to go out in the next prerelease of the extension. This (and a slew of similar bugs) will be re-verified if they are reproducing still

[ryzngard]

This should be available now with v2.39.28 (pre-release)

[marcel2215]

Even after updating to C# 2.39.28 (pre-release) and C# Dev Kit v1.9.8 (pre-release) I am still having this issue.

In my case I have a solution containing two projects: DopamineUI.csproj and DopamineUIPreview.csproj. The former contains the code of all components.

When I launch Visual Studio Code, I open the entire dopamine-ui folder in one window so I can access both source and preview at the same time. Everything compiles and runs fine, but working with 400+ ghost warnings/errors is not a pleasant experience.

A workaround is to open both projects (src and preview subfolders) in separate windows, but doing so creates unwanted src/src.sln and preview/preview.sln files. Both projects are already referenced in DopamineUI.sln.

Moreover, the existence of the preview.sln file is preventing me from using dotnet watch command. This is likely because it detects both DopamineUI.sln and preview/preview.sln. I am limited to launching via FN + F5 or dotnet run as these are unaffected. I have tried running dotnet watch --project DopamineUIPreview.csproj but got the same MSB1011 error. However, this is a problem with the dotnet itself and not the extension.

Deleting preview.sln solves the dotnet watch problem but it causes these 400+ warnings to reappear as components are not detected again.

Details
OS: macOS Sonoma 14.5
VS Code: 1.91.1
C# Extension: v2.39.28 (pre-release)
C# Dev Kit: v1.9.8 (pre-release)
.NET: 8.0

The project I am working on is open-source and pinned on my GitHub profile. Feel free to use it to investigate/reproduce the issue.

[marcel2215]

I have now tested it on my Windows PC and everything is exactly the same - so the problem is not related to just macOS.

[ryzngard]

Thanks @marcel2215 , reopening

[bpsc-wkubis]

Bumping up, got still same issues as @marcel2215

[dawidkacprzak]

Hi, for me the 'solution (if we can name that..) is to just add using to namespace.
I don't know how does it work in more complex solutions - probably pain in the ... but it works for me.

Just add usings on the top of the file.

It looks like the _Imports.razor is not working as should be for IDE extension. (For build it's ok)

Attached screenshot before and after using.

What's more interesting after additional using i can remove it after build and IDE looks fixed for all other usings... really weird

[ryzngard]

Hi, for me the 'solution (if we can name that..) is to just add using to namespace. I don't know how does it work in more complex solutions - probably pain in the ... but it works for me.

Just add usings on the top of the file.

It looks like the _Imports.razor is not working as should be for IDE extension. (For build it's ok)

Attached screenshot before and after using.

What's more interesting after additional using i can remove it after build and IDE looks fixed for all other usings... really weird

This sounds like what should be fixed in pre-release. I'm investigating the repro with DopamineUI today

[dawidkacprzak]

Hi, for me the 'solution (if we can name that..) is to just add using to namespace. I don't know how does it work in more complex solutions - probably pain in the ... but it works for me.
Just add usings on the top of the file.
It looks like the _Imports.razor is not working as should be for IDE extension. (For build it's ok)
Attached screenshot before and after using.
What's more interesting after additional using i can remove it after build and IDE looks fixed for all other usings... really weird

This sounds like what should be fixed in pre-release. I'm investigating the repro with DopamineUI today

Ah, i did not mentioned. I was reproducing that on newest pre-release version of C# extension and latest release as well - same result. What's important i'm using linux OpenSuse tumbleweed (latest) so it looks like OS independed failure. I think we can label it ' linux ' as weel

[ryzngard]

@marcel2215 one thing I should mention to help alleviate some of the pain: you can disable solution creation by setting

"dotnet.automaticallyCreateSolutionInWorkspace": false

[ryzngard]

Alright, I've got a repro of DopamineUI. I will see about testing on OpenSuse tumbleweed.

I filed dotnet/razor#10654 to better track the DopamineUI issue.
I filed dotnet/razor#10655 for the OpenSuse tumbleweed issue.

This issue as originally filed is fixed. I'll see if I can root cause the two new issues, but this issue is "resolved" in the sense that "Component discovery is not completely broken on MacOS anymore".

Thank you for the detailed information @marcel2215 and @dawchelstowski