Remove reference to PhysicalFileProvider from WebView

[Eilon]

Fixes #35707

Description

.NET MAUI apps currently have a reference to MS.Extensions PhysicalFileProvider that comes from ASP.NET's WebViewManager. The PhysicalFileProvider includes reference to system file watchers (whether you're actually watching for file changes or not). This reference prevents it from being accepted in certain app stores that restrict usage of file system watchers.

In this change the base WebViewManager class has a new virtual method that can be overridden on platforms that use static web assets and need physical file system access. .NET MAUI will not override this method, avoiding the reference. (Other platforms, such as WPF/WinForms Blazor Desktop will override it and use PhysicalFileProvider.)

Note: None of Blazor Desktop actually uses file system watchers, but the API call graph means that even with trimming, the reference to the watchers makes it to the published app, potentially causing app store rejection.

Customer Impact

Cannot publish Blazor Desktop apps to the iOS App Store (this was confirmed by a customer).

Regression?

• Yes
• No

[If yes, specify the version the behavior has regressed from]

Risk

• High
• Medium
• Low

[Justify the selection above]

Verification

• Manual (required) - the only way to truly verify this fix does what we expect is to publish another app to the app store and wait ~1 week, but that is not feasible. So, I verified that there are no more references to PhysicalFileProvider or file watchers from WebViewManager (a core class in Blazor Desktop)
• Automated - CI tests pass

Packaging changes reviewed?

• Yes
• No
• N/A

Addresses #35707

[ghost]

Hello human! Please make sure you've included the Shiproom Template in a comment or (preferably) the PR description. Also, make sure this PR is not marked as a draft and is ready-to-merge.

[Pilchie]

Can you fill out the servicing template? For RC1, we need tactics approval at this point.

[Pilchie]

This is approved by Tactics, looks like you hit a build race that has been plaguing us lately :(

[Eilon]

I'm removing from RC1 because it turns out this change isn't strictly needed. In dotnet/runtime#57931 (which is in RC1), the disallowed iOS API isn't even called on iOS builds anymore, so using PhysicalFileProvider is perfectly safe from this perspective. However, we might still want to remove calls to PhysicalFileProvider simply because it isn't even needed on any .NET MAUI platforms.

[dougbu]

Suspect versions should be resolved in favour of what's in 'release/6.0' already. Is that correct @Eilon i.e. you didn't intentionally update the dependencies when targeting 'release/6.0'❔

Separately, has this change already been done in 'main'❔ Our current practise is to get things working in 'main' then use /backport to release/6.0-rc1 or /backport to release/6.0.

[github-actions]

Started backporting to release/6.0-rc1: https://github.com/dotnet/aspnetcore/actions/runs/1172020491

[github-actions]

@dougbu backporting to release/6.0-rc1 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: [release/6.0-rc1] Update dependencies from dotnet/efcore dotnet/runtime (#35736)
Using index info to reconstruct a base tree...
M	eng/Version.Details.xml
M	eng/Versions.props
Falling back to patching base and 3-way merge...
Auto-merging eng/Versions.props
CONFLICT (content): Merge conflict in eng/Versions.props
Auto-merging eng/Version.Details.xml
CONFLICT (content): Merge conflict in eng/Version.Details.xml
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 [release/6.0-rc1] Update dependencies from dotnet/efcore dotnet/runtime (#35736)
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

[dougbu]

Started backporting to release/6.0-rc1: https://github.com/dotnet/aspnetcore/actions/runs/1172020491

Now that's annoying. @wtgodbe is our comment parser too forgiving❔

[Eilon]

Oh I just re-targetted the PR, which totally messed it up. I'll close this and send a new PR when ready.

[dougbu]

Should we delete the branch❔

[Eilon]

No, I need the code in that branch.

[ghost]

Hi @Eilon. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.