Keep WebView modules fallback project-local

[PureWeen]

Keep WebView modules fallback project-local

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Keep the WebView modules fallback from flowing across project references.

Description

The conditional fallback introduced by #67375 and backported in #67401 correctly avoids colliding with an app-generated blazor.modules.json when a single consumer contributes JS modules. A remaining multi-project graph can still produce two fallbacks:

1. An executable Razor app directly references Microsoft.AspNetCore.Components.WebView.
2. A Razor class library also directly references the WebView package.
3. The app references the RCL.
4. Neither project contributes a JS module.

Both projects independently materialize the package's raw build/blazor.modules.json. Because the fallback was authored with AssetMode="All", the RCL asset flows across the project-reference boundary as SourceType=Project, SourceId=rcl. It then conflicts with the app's independently materialized SourceType=Discovered, SourceId=app asset at _framework/blazor.modules.json.

This changes the fallback to AssetMode="CurrentProject". That keeps the fallback available to each direct consumer while preventing a library-owned fallback from flowing into referencing projects. It matches the SDK's own build and publish JS-module manifests, which are also current-project-only. SDK conflict detection remains strict; the malformed duplicate is prevented at the package-authoring boundary rather than suppressed during aggregation.

The build-behavior coverage now includes the exact direct/direct no-module graph and a sibling graph where the directly-referencing RCL contributes a JS module. The consumer-build helper also omits an optional local package source when its directory does not exist and narrows network-failure detection so a missing local source cannot silently skip product assertions.

Validation

The exact new no-module assertion failed before the product change with:

Conflicting assets with the same target path '_framework/blazor.modules.json'

After changing the fallback to CurrentProject, the same assertion passes and publishes one empty [] manifest.

All five WebViewBuildBehaviorTests pass against current main, covering:

• app plus RCL modules with a package reference;
• app-only empty fallback;
• app and RCL both directly referencing WebView with no modules;
• app and RCL both directly referencing WebView with RCL modules;
• WebView source-project/P2P consumption with RCL modules.

Related context: #67375, #67401, and dotnet/sdk#54779.

[Copilot]

Pull request overview

This PR adjusts the WebView _framework/blazor.modules.json fallback static web asset so it remains available to each direct consumer project while preventing a library-owned fallback from flowing across ProjectReference boundaries and causing duplicate-asset conflicts during static web assets aggregation.

Changes:

• Change the WebView modules fallback asset authoring from AssetMode="All" to AssetMode="CurrentProject" to prevent project-reference propagation.
• Add end-to-end publish tests covering the direct app + direct RCL WebView-reference graphs (with and without RCL JS modules) to validate a single manifest is produced/served.
• Make consumer test build infrastructure more robust by omitting a non-existent local package source and tightening “network failure” detection so missing local sources don’t cause silent skips.

Show a summary per file

File	Description
src/Components/WebView/WebView/src/StaticWebAssets.Groups.targets	Keeps the modules-manifest fallback scoped to the current project to avoid cross-project duplicate assets.
src/Components/WebView/test/StaticWebAssets/WebViewBuildBehaviorTests.cs	Adds publish-behavior coverage for app+RCL graphs where both reference WebView, asserting exactly one served/published manifest.
src/Components/WebView/test/StaticWebAssets/ConsumerBuild.cs	Improves hermetic consumer build setup by conditionally adding local feeds and refining network-failure skip detection.

Review details

Tip

Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Lite