PersistentComponentState in Maui Blazor

[mstancombe]

Description

When maui blazor renders a component that injects the PersistentComponentState, it fails.

This documentation shows how to use persisted state in a component.
https://docs.microsoft.com/en-us/aspnet/core/blazor/components/prerendering-and-integration?view=aspnetcore-6.0&pivots=server#persist-prerendered-state

When a component that injects PersistentComponentState is placed into a blazor server or wasm library, it works, as the server library adds it here:

aspnetcore/src/Mvc/Mvc.ViewFeatures/src/DependencyInjection/MvcViewFeaturesMvcCoreBuilderExtensions.cs

Line 242 in c85baf8

services.TryAddScoped<PersistentComponentState>(sp => sp.GetRequiredService<ComponentStatePersistenceManager>().State);

And the wasm adds it in the builder here:

aspnetcore/src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHostBuilder.cs

Line 268 in de68fea

Services.AddSingleton<PersistentComponentState>(sp => sp.GetRequiredService<ComponentStatePersistenceManager>().State);

However, this doesn't appear to be added in Maui anywhere, and due to this, when maui blazor includes a component that injects the PersistentComponentState, it will cause an error.

Manually adding the registrations during maui building resolves this, as per workaround.

Steps to Reproduce

1. Clone the repro
2. Try run MauiApp2. First page will show yellow error bar
3. Uncomment lines 23/24 of MauiProgram.cs
4. Run it again, and it will now work

Link to public reproduction project repository

https://github.com/mstancombe/MauiBlazorPersistantStateIssueRepro

Version with bug

6.0.400

Last version that worked well

Unknown/Other

Affected platforms

Android, Windows

Affected platform versions

Windows 11

Did you find any workaround?

Using the same registration as the WASM builder does in MauiProgram resolves this:

Relevant log output

No response

[javiercn]

@mstancombe thanks for contacting us.

This is a bug on our side.

Thanks for contacting us.

We're moving this issue to the .NET 8 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.

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.