Move Blazor endpoints source generation into Razor compiler

[SteveSandersonMS]

@javiercn You mentioned this work yesterday. Could you fill in details?

Also, in terms of ordering the work, am I right to believe we could schedule this pretty late, since if we don't make it then the reflection-based approach will work anyway and the sourcegen can be slotted in any time nonbreakingly?

[SteveSandersonMS]

Thinking about this more, I don't quite see how it could work. We don't require people to use the Razor compiler to author their page components, so what happens for people who implement a component in plain .cs with [Route]?

[javiercn]

@SteveSandersonMS it gets picked up anyways.

The only thing that putting this logic in the compiler does is ensure we can "see" the .razor files being transformed into types. Our logic is completely independent of .razor in that sense.

If you are asking what happens if someone disables the razor source generator, then you don't get discovery and don't get auto detection of render modes. You can manually write the code to produce the same outcome as the source generator.

[SteveSandersonMS]

Right yes, there's nothing stopping it from discovering all component types regardless of whether they were originally implemented as .razor files or in .cs. Makes sense.

If you are asking what happens if someone disables the razor source generator,

Not really, I don't think we have to worry about that.

[SteveSandersonMS]

@javiercn @mkArtakMSFT Am I right to think we could push this out for now? AFAIK the reflection-based page discovery is already working fine and customers won't see any particular benefit from switching to a sourcegenerator-based one for .NET 8, since it doesn't support any broader thing that may require it (e.g., AOT). And for rendermodes, it's better to do that based on which DI services are registered as that will be simpler and more reliable (e.g., will work with callsite rendermodes too).

If that's the case it would definitely be good to focus our efforts on the essential things that we must ship first.

[buvinghausen]

The .NET 8 feature I was most looking forward to using was Blazor United but unfortunately for us each microservice defines its own razor class library each containing several routable components. This slipping to .NET 9 means we dont get to use the new feature until 9/2024 at the earliest which is disappointing to say the least.

[SteveSandersonMS]

@buvinghausen Is your requirement simply to have routable components spread across multiple class libraries? If so that's fine and is supported in .NET 8. We didn't cut the feature; we just changed how it was implemented.

[buvinghausen]

@SteveSandersonMS thanks for the clarification

[darena-pjindal]

@SteveSandersonMS - could you please clarify the final decision/API to map razorcomponents from multiple web assemblies? I looked at all the related posts but couldn't find what was implemented. My apologies if I missed but it seems that it still supports only one class library. Is there any support planned to have functionality similar to the additional assemblies parameter like before? To clarify, I am looking for routing components to be spread over various libraries.

[buvinghausen]

@darena-pjindal as far as I know the functionality is not available in preview 7 I have a very slimmed down project that I will test RC1 on when it drops next week. Fingers crossed it is available because I really want to use the new hosting model but not being able to have microservices define routes is definitely a deal breaker.

[darena-pjindal]

@darena-pjindal as far as I know the functionality is not available in preview 7 I have a very slimmed down project that I will test RC1 on when it drops next week. Fingers crossed it is available because I really want to use the new hosting model but not being able to have microservices define routes is definitely a deal breaker.

Thanks @buvinghausen . I was confused by the reply above and many related posts that mentioned an "Api" to do that.

[buvinghausen]

@darena-pjindal I just downloaded RC1 and it appears they added an extension method AddAdditionalAssemblies to the RazorComponentsEndpointConventionBuilder which does allow routing to RCL pages in the minimalistic project that I whipped together after preview 6 dropped.

I don't have time this week but I will try to port our running main application over to .NET 8 RC1 this weekend with the new Blazor hosting mode and see if I lose much in the way of limbs/blood and will report back ;-)

[darena-pjindal]

Thanks so much, @buvinghausen. i also just saw the you tube stream and was getting ready to try it out. I will try it out right away. Exciting stuff!

[buvinghausen]

One thing I did notice in my extremely cursory testing since it appears the App.razor Router is basically ignored is the NotFound experience returns back a generic message

I also see a new EndpointFilterExtensions class with extension methods that I'm hoping will allow us to exclude certain paths from the Blazor routing i.e starts with /api, /hub, /grpc, etc which then would just leave the Blazor 404 route UI as the lone thing to resolve.

Good luck on the path

[TimPurdum]

Tested on RC-1, the following extension makes this work again!

app.MapRazorComponents<App>()
    .AddAdditionalAssemblies(typeof(MainLayout).Assembly);

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. 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.

[mkArtakMSFT]

Closing as a dupe of https://github.com/dotnet/aspnetcore/issues/46980