Components added by a source generator work in code, but not in markup

[SQL-MisterMagoo]

If a component is added to the compilation by a source generator, it is recognised by intellisense correctly, and will render correctly if referenced in c# code e.g. OpenComponent<MyComponent>(1), but triggers a warning and does not render if referenced in markup e.g. <MyComponent/>

Filed using Visual Studio feedback here : https://developercommunity.visualstudio.com/t/Razor-Components-which-are-added-by-a-3r/1400911

The problem can be seen in the generated code attached and on the feedback issue:
_Pages_Index.razor.cs.zip

In the C# @code section of the razor file, it correctly allows use of the component class:

b.OpenComponent<Component1>(1);
b.CloseComponent();

But in the code generated from the Razor markup, it turns the component into an element

__builder.OpenElement(8, "Component1");
__builder.CloseElement();

Sample repo: https://github.com/SQL-MisterMagoo/SGProblem

Clone it git clone https://github.com/SQL-MisterMagoo/SGProblem.git
Run it dotnet run --project SampleWASM\SampleWASM.csproj

Environment:

Microsoft Visual Studio Enterprise 2019 Preview
Version 16.10.0 Preview 2.1
.NET SDK 6.0.100-preview.3.21202.5

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[BerserkerDotNet]

I have similar experience with POCO classes generated using source generators. @mkArtakMSFT, I believe the reason is #26902 (PR: #28807). If I understand correctly, razor files are now "compiled" through source generator and source generators can't see one another output.

Run un-ordered, each generator will see the same input compilation, with no access to files created by other source generators.

https://github.com/dotnet/roslyn/blob/main/docs/features/source-generators.md#high-level-design-goals

[pranavkm]

We've asked the compiler team to look at adding support for ordering source generators which should also allow generators to look at the output from previously generated items. We're still hopeful they would be able to do some tactical, but it's more likely that this would be unable to resolve it for the 6.0 / VS 2022 release.

As a workaround, we've added a switch to the RazorSDK to opt-out of using the Razor source generator. To do so, update the project file like so:

<PropertyGroup>
  <UseRazorSourceGenerator>false</UseRazorSourceGenerator>
</PropertyGroup>

This should revert Razor's compilation to the 5.0 behavior. The side-effects of reverting to the old model include lack of support for hot reload for .razor and .cshtml files, and reverting the changes described in aspnet/Announcements#459 (you get a .Views assembly similar to 5.0). While we don't think these are ideal solutions, this should stave you over until the compiler adds support for ordering.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[TanayParikh]

Marking as external given:

We've asked the compiler team to look at adding support for ordering source generators which should also allow generators to look at the output from previously generated items.

[pranavkm]

Let's use dotnet/roslyn#57239 to further track this as it's primarily compiler work.