Skip to content

Pre-generate publish-compressed framework assets during build#67500

Open
wtgodbe wants to merge 2 commits into
dotnet:mainfrom
wtgodbe:wtgodbe/precompress-swa-publish
Open

Pre-generate publish-compressed framework assets during build#67500
wtgodbe wants to merge 2 commits into
dotnet:mainfrom
wtgodbe:wtgodbe/precompress-swa-publish

Conversation

@wtgodbe

@wtgodbe wtgodbe commented Jun 30, 2026

Copy link
Copy Markdown
Member

Problem

Parallel consumer publishes intermittently fail the Build shared fx / publish legs with:

Microsoft.NET.Sdk.StaticWebAssets.Compression.targets(359,5): error : The process cannot access the file '...compressed/publish/*.br' because it is being used by another process.

Root-caused from the binlog of build 1482653 (Tests: Helix x64 Subset 1 / Build shared fx): two consumers (Components.Authorization on node 3, Components.Gateway on node 1) each trigger a publish of the shared Microsoft.AspNetCore.App.Internal.Assets project concurrently on different MSBuild nodes. Both run GeneratePublishCompressedStaticWebAssets against the same producer obj dir ($(IntermediateOutputPath)compressed/publish), so one writes the .br while the other reads/writes it → sharing violation. Survey: ~16/308 builds over 7 days on def 83.

The SDK ties the compressed output path to the producing project's IntermediateOutputPath (no per-consumer override exists), and the per-node result cache doesn't dedupe the publish invocation across nodes.

Fix (mitigation)

Run the publish-compression once during App.Internal.Assets' own (single, ordered) build via an AfterTargets="Build" target. The compress tasks are incremental, so by the time consumers publish, the .br/.gz are already up-to-date and the concurrent invocations skip the write — leaving only safe concurrent reads.

Parallel consumer publishes each trigger Microsoft.AspNetCore.App.Internal.Assets'
publish-compression in its shared obj dir on different MSBuild nodes, racing on the
same .br/.gz output and intermittently failing with 'file is being used by another
process'. Running the compression once during this project's (ordered, single) build
warms the incremental cache so later concurrent publishes skip the write.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@wtgodbe wtgodbe marked this pull request as ready for review July 1, 2026 00:35

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Mitigates intermittent parallel publish failures in the shared framework build by pre-generating publish-compressed Static Web Assets during the producer project’s ordered build, so later concurrent consumer publishes should hit incremental outputs rather than racing on shared obj paths.

Changes:

  • Adds an MSBuild target to warm publish-compressed static web assets after Build.
  • Gates the new target on NodeJS builds and compression being enabled.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Disable compression, we don't need it enabled here <CompressionEnabled>false</CompressionEnabled>. We don't put compressed assets on packages and they'll be compressed by the final app

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants