Static Web Assets: apply deferred asset group resolution during publish by Copilot · Pull Request #54941 · dotnet/sdk

Copilot · 2026-06-23T14:19:44Z

Deferred Static Web Asset groups were resolved during build but never during publish. When two grouped variants resolved to the same route with AssetKind=All (e.g. a package fallback plus an app-generated asset), the variant the group was supposed to exclude survived into the publish pipeline and GenerateStaticWebAssetEndpointsManifest threw InvalidOperationException: Sequence contains more than one element. The same project built successfully.

Root cause

The build manifest intentionally retains all group variants so transitive consumers can re-resolve against their own graph. Publish reloads that manifest but:

never re-resolves deferred groups (no publish-side FilterDeferredStaticWebAssetGroups), and
its FilterStaticWebAssetGroups is consumer-scoped (Source="$(PackageId)"), so it structurally cannot filter groups owned by a referenced project or NuGet package.

Re-resolving at publish from the package can't fix this — the decision has to be made where the filter is unscoped (build) and carried forward.

Changes

Persist resolved groups in the build manifest — StaticWebAssetGroup is now public/serializable with round-trip (ToTaskItem/FromItemGroupToArray) and value equality; StaticAssetsManifest gains a Groups property wired into Create/hash/equals. GenerateStaticWebAssetsManifest writes the resolved (no-longer-Deferred) groups into staticwebassets.build.json.
Surface groups on read — ReadStaticWebAssetsManifestFile exposes a new StaticWebAssetGroups output.
Re-apply the unscoped decision at publish — LoadStaticWebAssetsBuildManifest re-runs FilterStaticWebAssetGroups (unscoped) using the persisted groups, dropping the excluded variant before the publish endpoints manifest is computed. Build-time groups are also cached (_CachedBuildStaticWebAssetGroups) so the in-process build+publish path is covered alongside fresh/no-build publishes that read from the manifest.
Regression test — adds a publish case to DeferredAssetGroupsIntegrationTest where two AssetKind=All variants collapse to one route, owned by a referenced project, and asserts exactly one asset/endpoint survives.

Because the build manifest still retains all variants, transitive consumers continue to re-import the deferred group definitions and re-resolve against their own graph; persistence only governs the current project's build→publish consistency.

Copilot

Pull request overview

This PR fixes a build→publish inconsistency in the Static Web Assets pipeline by persisting resolved (non-deferred) asset group decisions into the build manifest and then re-applying that decision during publish when the build manifest is loaded, preventing duplicate assets/endpoints from surviving into publish and causing endpoint manifest generation failures.

Changes:

Persist resolved StaticWebAssetGroup data into staticwebassets.build.json and expose it when reading manifests.
Re-apply group filtering during publish after reloading the build manifest (including in-process build+publish via cached groups).
Add an integration test covering the publish scenario where two variants collapse to the same route and only one should survive.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
test/Microsoft.NET.Sdk.StaticWebAssets.Tests/DeferredAssetGroupsIntegrationTest.cs	Adds a publish regression test validating only one grouped variant/endpoints survive publish.
src/StaticWebAssetsSdk/Tasks/ReadStaticWebAssetsManifestFile.cs	Adds `StaticWebAssetGroups` output when reading a manifest.
src/StaticWebAssetsSdk/Tasks/GenerateStaticWebAssetsManifest.cs	Captures `@(StaticWebAssetGroup)` input and persists resolved groups into the manifest.
src/StaticWebAssetsSdk/Tasks/Data/StaticWebAssetGroup.cs	Makes `StaticWebAssetGroup` public/serializable with task-item roundtrip + value equality/hash.
src/StaticWebAssetsSdk/Tasks/Data/StaticAssetsManifest.cs	Adds `Groups` to the build manifest model, hash computation, and equality/hash code.
src/StaticWebAssetsSdk/Targets/Microsoft.NET.Sdk.StaticWebAssets.targets	Passes groups into build manifest generation and caches build-time groups for in-proc publish.
src/StaticWebAssetsSdk/Targets/Microsoft.NET.Sdk.StaticWebAssets.Publish.targets	Reloads groups from build manifest and re-filters assets/endpoints during publish using persisted groups.

+            var publish = CreatePublishCommand(projectDirectory, "AppWithP2PReference");
+            ExecuteCommand(publish).Should().Pass();
+
+            var intermediateOutputPath = publish.GetIntermediateDirectory(DefaultTfm, "Debug").ToString();


…otnet/sdk#54941) Reverts the framework-asset modeling and the in-package publish workaround. With the SDK fix in dotnet/sdk#54941 (resolved deferred static web asset groups are persisted into the build manifest and re-applied, unscoped, when the manifest is reloaded at publish), the idiomatic deferred-group authoring that the WebView package already uses is correct end-to-end: blazor.modules.json is a Package static web asset in the deferred BlazorWebViewModules group, resolved to drop the fallback when the app contributes its own JS modules and keep it otherwise. No framework-asset hack and no package-local workaround are needed, so the WebView product files are unchanged from main. This PR now contributes the static web assets packaging + build/publish regression tests: - Package-layout tests assert the deferred-group shape for WebView (modules.json = Package in BlazorWebViewModules=fallback; webview.js = Framework) and the framework/group shapes for Components.WebAssembly, App.Internal.Assets and Identity.UI. - Build/publish behavior tests (package consumer and ProjectReference consumer) assert a single _framework/blazor.modules.json endpoint and that the app's manifest supersedes the fallback. The publish assertions are skipped until dotnet/sdk#54941 is in the repo SDK (detected via the pre-fix 'Sequence contains more than one element' crash) so the suite stays green meanwhile. Note: this PR depends on dotnet/sdk#54941 flowing into the repo SDK; until then the in-repo WebView publish path (and the publish tests) require that fix. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

javiercn

@copilot address feedback

Copilot · 2026-06-23T20:21:01Z

@copilot address feedback

Added Publish_NoBuild_DeferredGroupWithTwoVariantsOnSameRoute_KeepsSingleVariant in commit 539a85c→latest. The new test builds the project first, then republishes with /p:NoBuild=true to exercise the ReadStaticWebAssetsManifestFile → LoadStaticWebAssetsBuildManifest disk-read path, asserting that exactly one asset/endpoint survives on the shared route. Also updated the CreateTwoVariantDeferredGroupProject helper to accept a [CallerMemberName] parameter included in the identifier so each test method gets its own isolated test asset directory.

#67374) The WebView package ships a fallback _framework/blazor.modules.json (empty []) for apps that contribute no JS library modules. Modeling it as a deferred static web asset group required tagging/promoting the consumer's SDK-generated manifest and depended on an SDK fix (dotnet/sdk#54941) to filter the group at publish; without it, publish crashed with "Sequence contains more than one element" (#67374). Replace the group authoring with conditional materialization: the package ships the fallback raw under build/ (not as a flowing static web asset) and materializes it as the consumer's own asset during ResolveStaticWebAssetsInputs ONLY when the app has no JS modules of its own. The decision runs before the build manifest / conflict check, so exactly one asset ever lands on _framework/blazor.modules.json and there is never a conflict at build or publish. No asset groups, no consumer manifest tagging, no SDK dependency. Tests validate the package layout and build/publish behavior (package + P2P consumers, with and without JS modules) by cracking the built .nupkg and running isolated consumer builds under artifacts/ with binlog capture. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…nifest groups Co-authored-by: javiercn <6995051+javiercn@users.noreply.github.com>

Co-authored-by: javiercn <6995051+javiercn@users.noreply.github.com>

…fest Co-authored-by: javiercn <6995051+javiercn@users.noreply.github.com>

…upProject Co-authored-by: javiercn <6995051+javiercn@users.noreply.github.com>

…otnet/sdk#54941) Reverts the framework-asset modeling and the in-package publish workaround. With the SDK fix in dotnet/sdk#54941 (resolved deferred static web asset groups are persisted into the build manifest and re-applied, unscoped, when the manifest is reloaded at publish), the idiomatic deferred-group authoring that the WebView package already uses is correct end-to-end: blazor.modules.json is a Package static web asset in the deferred BlazorWebViewModules group, resolved to drop the fallback when the app contributes its own JS modules and keep it otherwise. No framework-asset hack and no package-local workaround are needed, so the WebView product files are unchanged from main. This PR now contributes the static web assets packaging + build/publish regression tests: - Package-layout tests assert the deferred-group shape for WebView (modules.json = Package in BlazorWebViewModules=fallback; webview.js = Framework) and the framework/group shapes for Components.WebAssembly, App.Internal.Assets and Identity.UI. - Build/publish behavior tests (package consumer and ProjectReference consumer) assert a single _framework/blazor.modules.json endpoint and that the app's manifest supersedes the fallback. The publish assertions are skipped until dotnet/sdk#54941 is in the repo SDK (detected via the pre-fix 'Sequence contains more than one element' crash) so the suite stays green meanwhile. Note: this PR depends on dotnet/sdk#54941 flowing into the repo SDK; until then the in-repo WebView publish path (and the publish tests) require that fix. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

#67374) The WebView package ships a fallback _framework/blazor.modules.json (empty []) for apps that contribute no JS library modules. Modeling it as a deferred static web asset group required tagging/promoting the consumer's SDK-generated manifest and depended on an SDK fix (dotnet/sdk#54941) to filter the group at publish; without it, publish crashed with "Sequence contains more than one element" (#67374). Replace the group authoring with conditional materialization: the package ships the fallback raw under build/ (not as a flowing static web asset) and materializes it as the consumer's own asset during ResolveStaticWebAssetsInputs ONLY when the app has no JS modules of its own. The decision runs before the build manifest / conflict check, so exactly one asset ever lands on _framework/blazor.modules.json and there is never a conflict at build or publish. No asset groups, no consumer manifest tagging, no SDK dependency. Tests validate the package layout and build/publish behavior (package + P2P consumers, with and without JS modules) by cracking the built .nupkg and running isolated consumer builds under artifacts/ with binlog capture. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI assigned Copilot and javiercn Jun 23, 2026

Copilot started work on behalf of javiercn June 23, 2026 14:20 View session

Copilot AI changed the title ~~[WIP] Fix deferred asset group resolution during publish~~ Static Web Assets: apply deferred asset group resolution during publish Jun 23, 2026

Copilot AI requested a review from javiercn June 23, 2026 14:49

Copilot finished work on behalf of javiercn June 23, 2026 14:49

javiercn marked this pull request as ready for review June 23, 2026 15:01

Copilot AI review requested due to automatic review settings June 23, 2026 15:01

Copilot started reviewing on behalf of javiercn June 23, 2026 15:02 View session

Copilot AI reviewed Jun 23, 2026

View reviewed changes

javiercn mentioned this pull request Jun 23, 2026

[Blazor] Fix WebView blazor.modules.json publish crash via conditional fallback (#67374) dotnet/aspnetcore#67375

Open

This was referenced Jun 23, 2026

One process not started with aspire integ test #54921

Open

MTPHelpSnapshotTests.VerifyMTPHelpOutput snapshot mismatch (--progress option added) #54948

Closed

javiercn reviewed Jun 23, 2026

View reviewed changes

Copilot started work on behalf of javiercn June 23, 2026 20:08 View session

Copilot finished work on behalf of javiercn June 23, 2026 20:21

Copilot AI requested a review from javiercn June 23, 2026 20:21

Copilot AI and others added 5 commits June 23, 2026 19:41

Initial plan

b352250

Apply deferred SWA group resolution at publish via persisted build-ma…

4732181

…nifest groups Co-authored-by: javiercn <6995051+javiercn@users.noreply.github.com>

Clarify comments for deferred group publish re-application

38e6071

Co-authored-by: javiercn <6995051+javiercn@users.noreply.github.com>

Add NoBuild publish test for deferred group resolution from disk mani…

48cf83a

…fest Co-authored-by: javiercn <6995051+javiercn@users.noreply.github.com>

Use identifier pattern for caller name in CreateTwoVariantDeferredGro…

d8a29aa

…upProject Co-authored-by: javiercn <6995051+javiercn@users.noreply.github.com>

lewing force-pushed the copilot/fix-deferred-asset-group-resolution branch from 5415398 to d8a29aa Compare June 24, 2026 00:45

build-analysis Bot mentioned this pull request Jun 24, 2026

Template engine tests hitting known parallelism issue in GetVisualStudioInstances #44878

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Static Web Assets: apply deferred asset group resolution during publish#54941

Static Web Assets: apply deferred asset group resolution during publish#54941
Copilot wants to merge 5 commits into
mainfrom
copilot/fix-deferred-asset-group-resolution

Copilot AI commented Jun 23, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

javiercn left a comment

Uh oh!

Copilot AI commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

Copilot AI commented Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Root cause

Changes

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

javiercn left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copilot AI commented Jun 23, 2026 •

edited

Loading