Custom BeforeBuild target's generated wwwroot file missing from staticwebassets.endpoints.json depending on build environment

[Popl7]

Summary

A custom MSBuild target that generates a file into wwwroot and is hooked at BeforeTargets="BeforeBuild" produces the file correctly on disk during dotnet publish, but the file's route is sometimes entirely missing from the generated {Project}.staticwebassets.endpoints.json, so MapStaticAssets() never registers an endpoint for it — every request 404s, even though the file exists in the published output at the correct size/content.

This isn't just "wrong extensibility point" (see #68108, which recommends BeforeTargets="AssignTargetPaths" for this exact scenario). In our case, moving the hook there (and to AssignTargetPaths;Publish), and separately splitting dotnet build + dotnet publish --no-build into two invocations, both still reproduced the bug. The only thing that reliably avoided it was generating the file in a fully separate process before invoking dotnet build/publish at all.

More surprisingly, the bug is highly environment-sensitive in a way that doesn't correlate with CPU/memory:

• Building and running the exact same commit locally (Docker Desktop on macOS, both native arm64 and via QEMU amd64 emulation, and via the classic non-BuildKit builder under --memory/--cpu-quota cgroup limits from 8 GB down to ~768 MB / 1 CPU before the build gets OOM-killed outright) always produces a correct manifest.
• Deploying the same commit to Render.com (their documented free-tier "Starter" build machine: 2 CPU / 8 GB RAM) always produces a manifest missing the route. Confirmed via a temporary diagnostic endpoint that the file was present on disk at the correct size; only the manifest entry was missing.
• Running the exact same Dockerfile in a minimal repro repo on GitHub Actions ubuntu-latest (4 CPU / 15 GB RAM, plain Docker Engine, no unusual sandboxing) also always reproduces it.

So it's not about being resource-starved — GitHub Actions' runner is more generously specced than several local configurations that worked fine. Whatever the actual trigger is, it's consistent within an environment and differs between environments in a way we couldn't pin down (our best untested guess: something about running inside a genuine Linux VM on a Linux hypervisor vs. Docker Desktop's macOS-hosted virtualization — but we didn't verify this).

Minimal repro

https://github.com/Popl7/essessay-tailwind-manifest-repro

• Essessay/Essessay.csproj defines:

  <Target Name="BuildTailwindCss" BeforeTargets="BeforeBuild" Inputs="@(TailwindInput)" Outputs="$(TailwindStamp);$(TailwindCss)">
      <Exec Command="&quot;$(TailwindExe)&quot; --input Styles/app.css --output wwwroot/css/site.css $(TailwindMinify)" WorkingDirectory="$(MSBuildProjectDirectory)" />
      <Touch Files="$(TailwindStamp)" AlwaysCreate="true" />
  </Target>

  generating wwwroot/css/site.css, referenced from a Razor view and served via app.MapStaticAssets() (Program.cs), .NET 10, Microsoft.NET.Sdk.Web.
• Essessay/Dockerfile builds it with a single RUN dotnet publish Essessay/Essessay.csproj -c Release -o /app --no-restore.
• .github/workflows/check-tailwind-manifest.yml builds the image with --no-cache on ubuntu-latest and greps the published Essessay.staticwebassets.endpoints.json for a css/site.css route, failing the job if it's missing.

Two runs, both failed the same way:

• https://github.com/Popl7/essessay-tailwind-manifest-repro/actions/runs/32241988885
• https://github.com/Popl7/essessay-tailwind-manifest-repro/actions/runs/32241993765

Relevant excerpt from the job log — the file exists, correctly sized, but only the unrelated Identity Razor Class Library's own css/site.css shows up:

--- disk ---
-rw-r--r-- 1 root root 38287 Aug 19 10:18 site.css
--- manifest routes for site.css ---
"Route":"Identity/css/site.css"
"Route":"Identity/css/site.css"
"Route":"Identity/css/site.css"
"Route":"Identity/css/site.css.br"
"Route":"Identity/css/site.css.gz"
FAIL: css/site.css route is MISSING from the manifest (bug reproduced)

You can re-run the workflow yourself via workflow_dispatch on that repo, or fork it — it's a full, working ASP.NET Core MVC app, --no-cache build, no other dependencies.

Expected

wwwroot/css/site.css, generated during BeforeBuild, gets a route in the published {Project}.staticwebassets.endpoints.json, deterministically, regardless of the machine/environment the build runs on.

Actual

The route is silently missing depending on the build environment (see above), despite the file itself being generated correctly every time.

What we tried

1. Baseline (BeforeTargets="BeforeBuild", single dotnet publish) — fails on GitHub Actions / Render, works locally.
2. Split dotnet build (with the target) + dotnet publish --no-build — still fails, even with the target's Exec running in a separate MSBuild invocation from the one that finalizes the publish manifest.
3. Re-hook at BeforeTargets="AssignTargetPaths;Publish" per How to add static assets for Blazor in a MSBuild Target #68108 (still one dotnet publish invocation) — still fails.
4. Workaround that holds: run the target as its own, fully separate process before dotnet build/publish starts at all (dotnet msbuild Essessay.csproj -t:BuildTailwindCss, then dotnet publish ... -p:SkipTailwindBuild=true to skip it the second time). This is the only approach that has served correctly across multiple Render deploys and would presumably also fix the GitHub Actions repro (untested there, since the repro repo intentionally keeps the original buggy Dockerfile).

Related, but not (as far as we could tell) duplicates

• How to add static assets for Blazor in a MSBuild Target #68108 — recommends AssignTargetPaths as the hook point; insufficient in our case.
• Microsoft.NET.Sdk.StaticWebAssets.targets unable to publish when static web assets been removed after build phase #56755, dotnet publish --no-build with separate build #46156 — both about the manifest going stale/missing relative to actual wwwroot content, but in different scenarios (files removed rather than added, and a hard failure rather than a silently incomplete manifest).

Happy to add more diagnostics to the repro repo if it helps narrow this down — e.g. dotnet --info, MSBuild binlog, or testing the AssignTargetPaths;Publish hook on GitHub Actions specifically.

[github-actions]

Triage Summary

Area: area-middleware (issue concerns StaticWebAssets manifest generation — staticwebassets.endpoints.json — and MapStaticAssets() endpoint registration)
Type: Bug (reporter demonstrates a reproducible defect: a generated wwwroot file's route is nondeterministically missing from the published manifest depending on build environment, despite the file existing on disk)

Potential Duplicates

• None found

Notes

• The reporter references issue How to add static assets for Blazor in a MSBuild Target #68108 as related (recommending AssignTargetPaths as the build hook), but that issue number could not be verified via the issue tracker.
• Reporter provides a public minimal repro repository and two GitHub Actions run logs demonstrating the failure, along with several workarounds already attempted (splitting build/publish, changing target hook points, running the generator as a separate process before dotnet build/publish).

Generated by Issue Triage Agent for dotnet/aspnetcore for #68641 · auto · 33.3 AIC · ⌖ 4.15 AIC · ⊞ 27.4K · ◷

[Popl7]

Update: stripped the repro repo down to a bare MVC app (one page, no Identity/EF/Redis/SSE — just HomeController → Index.cshtml, MapStaticAssets(), and the same BuildTailwindCss target and single-step dotnet publish Dockerfile as before): https://github.com/Popl7/essessay-tailwind-manifest-repro

Two things changed with the smaller app:

1. It now reproduces with a plain local docker build --no-cache, 3/3 runs, on the same machine where the original (much larger) app never once reproduced it, including under --memory/--cpu-quota throttling and amd64 QEMU emulation. Shrinking the app is what did it — flipped a build that previously always won the race into one that always loses it.
2. The manifest now has zero matches for site.css at all (no more Identity/css/site.css noise, since Identity is gone) — cleanest possible signature of the bug:

   --- disk ---
   -rw-r--r-- 1 root root <size> site.css
   --- manifest routes for site.css ---
   FAIL: css/site.css route is MISSING from the manifest (bug reproduced)
   

This points fairly strongly at a genuine race between BuildTailwindCss's Exec (bounded by downloading + running the Tailwind CLI) and however the SDK enumerates/finalizes static web assets for the manifest: the less other work (Razor/C# compilation, etc.) the rest of the build has to do, the more often the manifest-side wins and the route goes missing. That's consistent with what we saw across three real environments in the original report — it just took a smaller app to make it reproduce locally too.

Confirmed again on GitHub Actions ubuntu-latest with this smaller app: https://github.com/Popl7/essessay-tailwind-manifest-repro/actions/runs/32243477370 (and https://github.com/Popl7/essessay-tailwind-manifest-repro/actions/runs/32243486171 for a manual re-run).

[Popl7]

Follow-up: this has nothing to do with Tailwind, or with running an external process at all.

I tested two variants against the same app, both replacing the real Tailwind CLI invocation with a fake one, keeping only the BeforeTargets="BeforeBuild" hook and the same target shape:

Variant A — trivial external Exec, no download, no real binary:

<Target Name="BuildTailwindCss" BeforeTargets="BeforeBuild" Inputs="@(TailwindInput)" Outputs="...">
    <Exec Command="printf '...' &gt; wwwroot/css/site.css" WorkingDirectory="$(MSBuildProjectDirectory)" />
    <Touch Files="..." AlwaysCreate="true" />
</Target>

Reproduced the bug 3/3 local builds.

Variant B — no external process at all, a built-in synchronous MSBuild task:

<Target Name="GenerateSiteCss" BeforeTargets="BeforeBuild" Inputs="@(SiteCssInput)" Outputs="...">
    <MakeDir Directories="wwwroot/css" />
    <WriteLinesToFile File="wwwroot/css/site.css" Lines="..." Overwrite="true" />
    <Touch Files="..." AlwaysCreate="true" />
</Target>

Reproduced the bug 3/3 local builds, and confirmed again on GitHub Actions ubuntu-latest: https://github.com/Popl7/essessay-tailwind-manifest-repro/actions/runs/32246977167

Both give the identical signature — file present on disk with the expected content, zero routes for it in Essessay.staticwebassets.endpoints.json. Pushed variant B as a branch on the repro repo: https://github.com/Popl7/essessay-tailwind-manifest-repro/tree/no-external-process-repro

So this isn't about the Tailwind CLI's own I/O behavior, and it isn't about launching an external process vs. an in-process MSBuild task. It's purely: any target hooked at BeforeTargets="BeforeBuild" that writes a file into wwwroot races the SDK's static web assets discovery, regardless of how that file gets written or how long it takes. That's a much smaller surface to look at than "something about running Tailwind" — worth updating the title/scope if that's useful, happy to do so.

[Popl7]

Tested whether this predates .NET 9's MapStaticAssets(): pushed a .NET 8 variant of the same app (same GenerateSiteCss target, retargeted to net8.0 with UseStaticFiles() instead, since MapStaticAssets()/WithStaticAssets() don't exist before .NET 9): https://github.com/Popl7/essessay-tailwind-manifest-repro/tree/dotnet8-repro

Two-part finding:

1. The discovery gap already exists on .NET 8. obj/Release/net8.0/staticwebassets.build.json's Assets list only contains favicon.ico — site.css (written by the exact same BeforeBuild-hooked target) is missing from it, same as it's missing from Essessay.staticwebassets.endpoints.json on .NET 9/10. Same underlying MSBuild-level cause, present at least as far back as .NET 8.
2. But it's not observable as a runtime 404 on .NET 8. GET /css/site.css returns 200 with the correct content — UseStaticFiles() serves straight from WebRootFileProvider, a physical file provider pointed at wwwroot on disk, and never consults that manifest for a plain app's own assets. MapStaticAssets() (added in .NET 9) is what made this manifest load-bearing for that case — that's why the same discovery gap went from invisible to a production 404.

CI confirming both, on GitHub Actions ubuntu-latest: https://github.com/Popl7/essessay-tailwind-manifest-repro/actions/runs/32248396119 — one step dumps the discovered assets (favicon.ico only) and confirms site.css is missing from the build manifest, a separate step confirms the actual HTTP response is still 200.

So this isn't a .NET 9/10 regression in the discovery mechanism itself — the gap looks like it's always been there. It just didn't matter until MapStaticAssets() gave it a way to be user-visible. Might be worth checking .NET 9 specifically too to see whether it behaves like 8 (harmless) or like 10 (visible) — haven't tested that yet.

[Popl7]

Tested .NET 9 as well: https://github.com/Popl7/essessay-tailwind-manifest-repro/tree/dotnet9-repro

Same app, retargeted to net9.0 (the first TFM with MapStaticAssets()). Result: .NET 9 has the exact same user-visible bug as .NET 10 — site.css is missing from Essessay.staticwebassets.endpoints.json, and GET /css/site.css genuinely 404s at runtime, not just in the discovery manifest. So this isn't something newly introduced in .NET 10 — it's been there since MapStaticAssets() first shipped.

Confirmed on GitHub Actions ubuntu-latest, both build steps in one run: https://github.com/Popl7/essessay-tailwind-manifest-repro/actions/runs/32248855066

site.css is MISSING from the manifest on .NET 9 too (same as .NET 10)
GET /css/site.css -> 404
RESULT: 404 — same user-visible bug as .NET 10, already present on .NET 9

Combined with the earlier .NET 8 finding, the picture is now:

TFM	Discovery gap present?	User-visible (404)?
.NET 8	Yes (site.css missing from staticwebassets.build.json)	No — UseStaticFiles() doesn't consult that manifest
.NET 9	Yes	Yes — MapStaticAssets() does
.NET 10	Yes	Yes

So the underlying MSBuild-level discovery gap looks like it's been present since at least .NET 8, and became a real, user-facing bug the moment MapStaticAssets() shipped in .NET 9 and started depending on that manifest for correctness.

[Popl7]

Tested .NET 11 (preview) too: https://github.com/Popl7/essessay-tailwind-manifest-repro/tree/dotnet11-repro

Same app, retargeted to net11.0 against the mcr.microsoft.com/dotnet/sdk:11.0-preview / aspnet:11.0-preview images (SDK 11.0.100-preview.7.26381.103). Still the exact same bug — site.css missing from the manifest, GET /css/site.css 404s, 3/3 local builds.

Confirmed on GitHub Actions ubuntu-latest: https://github.com/Popl7/essessay-tailwind-manifest-repro/actions/runs/32249313450

site.css is MISSING from the manifest on .NET 11 too (same as .NET 9/10)
GET /css/site.css -> 404
RESULT: 404 — same user-visible bug as .NET 9/10, still present in .NET 11 preview

Updated picture across TFMs:

TFM	Discovery gap present?	User-visible (404)?
.NET 8	Yes	No — UseStaticFiles() doesn't consult the manifest
.NET 9	Yes	Yes
.NET 10	Yes	Yes
.NET 11 (preview)	Yes	Yes

Nothing about the 11.0-preview build changed the outcome, so as of now this doesn't look like something being incidentally fixed by ongoing SDK work — still open in the current preview.

[Popl7]

Follow-up on the "is BeforeBuild the correct hook" question: tested the complete official pattern from Microsoft's own guidance, not just the hook name — https://github.com/Popl7/essessay-tailwind-manifest-repro/tree/official-pattern-repro

Per Build client web assets for your Razor Class Library:

<Target Name="GenerateSiteCss" BeforeTargets="AssignTargetPaths" Inputs="@(SiteCssInput)" Outputs="$(IntermediateOutputPath)sitecss.complete.txt">
    <WriteLinesToFile File="$(IntermediateOutputPath)site.css" Lines="..." Overwrite="true" />
    <ItemGroup>
        <_GeneratedCss Include="$(IntermediateOutputPath)site.css" />
        <Content Include="@(_GeneratedCss)" Link="wwwroot/css/%(_GeneratedCss.Filename)%(_GeneratedCss.Extension)" />
        <FileWrites Include="@(_GeneratedCss)" />
    </ItemGroup>
    <WriteLinesToFile File="$(IntermediateOutputPath)sitecss.complete.txt" Lines="@(_GeneratedCss)" />
</Target>

Two things differ from every other variant tested so far:

1. The generated file is written to $(IntermediateOutputPath) (i.e. obj/), not directly into wwwroot.
2. It's registered as an explicit <Content Include="..." Link="wwwroot/..." /> item — an MSBuild item the target adds directly to the in-memory item graph — rather than relying on the SDK's wwwroot/** wildcard glob to notice a file that appeared on disk after project evaluation.

Result: this is the first variant that holds up. 4/4 local builds correct, and confirmed on GitHub Actions ubuntu-latest — the same environment that reliably 404'd on every "write straight into wwwroot" variant (Tailwind CLI, trivial Exec, WriteLinesToFile, on .NET 9/10/11 alike):
https://github.com/Popl7/essessay-tailwind-manifest-repro/actions/runs/32249965829

site.css IS in the manifest — the official pattern held up
GET /css/site.css -> 200
RESULT: served correctly (200) — the official pattern avoids the bug

So the earlier BeforeTargets="AssignTargetPaths" test (upthread) wasn't a fair test of the "official" recommendation — it changed the hook but still wrote straight into wwwroot and relied on glob rediscovery. That's the part that actually races. Declaring the output as an explicit Content/Link item, per Microsoft's own documented pattern, avoids it completely.

Worth noting BeforeBuild isn't actually documented anywhere as correct for this scenario in the first place — Microsoft's general MSBuild extensibility docs treat it as a legitimate generic customization point, but the ASP.NET Core-specific guidance for static web assets never mentions it, and goes straight to AssignTargetPaths + explicit Content items. So this bug is really "writing into wwwroot and expecting the wildcard glob to pick it up mid-build is unreliable," which happens to be exactly the pattern the official Tailwind CLI integration docs/samples float, and exactly what a lot of "add Tailwind/Sass/esbuild to a plain ASP.NET Core project" blog posts and templates out there teach. Might still be worth the SDK making that pattern deterministic (or documenting/erroring on it clearly), since it's evidently a very natural thing to reach for and silently wrong.

[Popl7]

Applied this fix to the real, full-size app this was originally extracted from (private repo, so no link — but confirmed working end to end) and it holds up in production, not just the minimal repro. Two extra gotchas showed up that anyone else applying this pattern will likely hit too, worth recording here:

1. $(IntermediateOutputPath) referenced through your own property, too early, silently captures an empty string.

<PropertyGroup>
    <TailwindCss>$(IntermediateOutputPath)site.css</TailwindCss>  <!-- BAD -->
</PropertyGroup>
...
<Target Name="BuildTailwindCss" ... Outputs="$(TailwindCss)">
    <Exec Command="tailwindcss --output &quot;$(TailwindCss)&quot;" />

$(IntermediateOutputPath) isn't set yet while a project's own top-level <PropertyGroup>s are evaluated — it only gets its real value later, from the implicit end-of-file SDK targets import. A property assigned from it earlier in the file permanently captures the empty string it had at that point, so $(TailwindCss) above silently becomes just "site.css" — written to the project root, not obj/, with no error at all (the build succeeds, the manifest is even correct, since the Content/Link item still gets built from whatever $(TailwindCss) expanded to). Only actually loading the page in a real deployment — or checking -v:normal output for the literal --output argument passed — surfaces it.

Fix: reference $(IntermediateOutputPath) directly inside the target's Outputs/Exec/ItemGroup (evaluated lazily, once the whole project including imports has been evaluated), not through a property assigned earlier in the file:

<Target Name="BuildTailwindCss" ... Outputs="$(IntermediateOutputPath)site.css">
    <Exec Command="tailwindcss --output &quot;$(IntermediateOutputPath)site.css&quot;" />
    <ItemGroup>
        <_GeneratedCss Include="$(IntermediateOutputPath)site.css" />
        <Content Include="@(_GeneratedCss)" Link="wwwroot/css/%(_GeneratedCss.Filename)%(_GeneratedCss.Extension)" />
    </ItemGroup>
</Target>

2. Anything else that still writes into wwwroot directly now conflicts with the Content/Link item.

The real app's dev loop (dotnet watch + a separate live Tailwind CLI process in --watch mode, for sub-100ms hot reload with no rebuild) writes the CSS straight into wwwroot/css/site.css on disk — deliberately, entirely outside MSBuild, for speed. That file is gitignored but not deleted between sessions. Once BuildTailwindCss switched to writing into obj/ + linking, the SDK's own wwwroot/** default-item glob still found that leftover physical file too, and the next plain dotnet build failed:

error : Two assets found targeting the same path with incompatible asset kinds:
error : '.../wwwroot/css/site.css' with kind 'All'
error : '.../obj/Release/net10.0/site.css' with kind 'All'
error : for path 'css/site#[.{fingerprint}]?.css'

Fix: explicitly exclude that physical path from the default item glob, so the Content/Link item is the only source of truth for it during a real build:

<ItemGroup>
    <Content Remove="wwwroot/css/site.css" />
</ItemGroup>

Neither of these is specific to Tailwind — both would bite anyone adapting the official Razor Class Library client-assets pattern for a top-level web app with any kind of separate live-reload/watch process for the same asset.

[Popl7]

Following up on "is BeforeBuild actually documented as correct anywhere" (upthread): I went looking for how this gets taught in practice — mainstream "add Tailwind/Sass/esbuild to ASP.NET Core" tutorials, not just Microsoft's own docs.

None of them use the literal name BeforeBuild. But every one I checked uses some other early-build hook, and — more importantly — every one shares the exact underlying flaw that caused this bug: writing the generated CSS/JS straight into wwwroot on disk, with no explicit <Content Include=".." Link="wwwroot/.." /> item and no $(IntermediateOutputPath) involved.

Source	Hook used	Output
khalidabuhakmeh.com — Install Tailwind CSS With ASP.NET Core	BeforeTargets="Build"	straight to wwwroot/css/output.css
stellaradmin.com — Add Tailwind 4 to ASP.NET Core 10	BeforeTargets="Build"	straight to ../wwwroot/css/site.css
aevitas.dev — Tailwind in ASP.NET Core	BeforeTargets="Build"	straight to wwwroot/css/styles.css
End Point Dev — esbuild + pnpm asset bundling	BeforeTargets="Build"	straight to wwwroot/css/site.css, wwwroot/js/site.js
jacobdixon.uk — Compile SCSS At Build Time	BeforeTargets="PreBuildEvent"	straight to wwwroot/css

Worth flagging: the stellaradmin.com post is specifically about .NET 10, the exact version where this bug is user-visible via MapStaticAssets(), and teaches the flawed pattern verbatim, today.

So the useful reframe here might not be "BeforeBuild is the wrong hook" — none of these use that literal name and all of them are equally broken — but "the entire genre of ASP.NET Core CSS/JS build-tool integration tutorials teaches a pattern that's silently unsafe under MapStaticAssets(), independent of which early-build hook name gets used." Given how common this pattern is (every mainstream tutorial I found does it this way), I'd guess there are real production apps hitting this right now without knowing why their CSS/JS 404s intermittently depending on deploy host — same as we did before filing this.

Not sure what the actionable fix on the framework side would be — maybe a diagnostic/analyzer warning when a Content item's physical path was modified after AssignTargetPaths-adjacent discovery ran, or documentation more prominently warning against writing directly into wwwroot from a build-time target — but wanted to leave this here in case it's useful context for triage.

[Popl7]

You asked a fair question about the previous comment — I hadn't actually tested the tutorials' exact hook choice, just asserted the pattern was the same shape. Tested it: https://github.com/Popl7/essessay-tailwind-manifest-repro/tree/tutorial-pattern-repro

<Target Name="Tailwind" BeforeTargets="Build">
    <Exec Command="npx @tailwindcss/cli -i ./css/site.css -o ../wwwroot/css/site.css" />
</Target>

BeforeTargets="Build" (the literal hook these tutorials use, not BeforeBuild, not AssignTargetPaths), no Inputs/Outputs, no Content/Link item — the exact shape from khalidabuhakmeh.com / stellaradmin.com / aevitas.dev, adapted to write via WriteLinesToFile instead of shelling out to npx (no Node dependency needed, and this repo has already shown Tailwind CLI vs. a trivial write makes no difference).

Confirmed broken, same as every other variant: 3/3 local builds, and on GitHub Actions ubuntu-latest:
https://github.com/Popl7/essessay-tailwind-manifest-repro/actions/runs/32253599916

site.css is MISSING — the tutorial pattern is broken under MapStaticAssets()
GET /css/site.css -> 404
RESULT: 404 — the real-world tutorial pattern hits the bug

So the earlier claim holds up under an actual test, not just an inference from "same shape": the literal code from a live, .NET-10-specific tutorial reproduces this bug 1:1.

[Popl7]

Traced this down to the actual source, for whoever picks this up — and it looks like the source has moved to dotnet/sdk, not this repo, so apologies if this should really be filed/transferred there.

The discovery target: dotnet/sdk@7053edd, Microsoft.NET.Sdk.StaticWebAssets.targets L768-L812:

<Target Name="ResolveProjectStaticWebAssets"
  Condition="'$(NoBuild)' != 'true'"
  BeforeTargets="AssignTargetPaths"
  DependsOnTargets="ResolveStaticWebAssetsConfiguration;UpdateExistingPackageStaticWebAssets;AssignLinkMetadata">
  ...
  <DefineStaticWebAssets
    CandidateAssets="@(Content->Distinct())"
    ...
    RelativePathPattern="wwwroot/**"
    SourceType="Discovered"
    ...

The key line is CandidateAssets="@(Content->Distinct())". This target doesn't scan the filesystem — it filters whatever's already in the Content item collection at the point it runs, down to wwwroot/**. That collection gets populated by the SDK's default-item globs at project evaluation time, which happens once, before any target executes.

That precisely explains the mechanism for the cases we could fully pin down: a plain file write from a BeforeBuild/Build-hooked target's Exec/task never touches the Content item collection — it just puts a file on disk. ResolveProjectStaticWebAssets never re-scans disk to notice it. Only two things get a file into Content in time for this target:

1. It was already on disk when the project was evaluated — which is exactly why the two example repos with a committed (not gitignored) CSS output file never hit this (dune-ui/blog-posts, khalidabuhakmeh/TailwindAspNetCore) — the stale file was already part of Content before the generating target ever ran.
2. An explicit <ItemGroup><Content Include=".." /></ItemGroup> inside the generating target itself — which is exactly what the working fix upthread does, and presumably why it holds up.

One thing I want to flag honestly rather than overclaim: this fully explains the committed-vs-gitignored split, but it does not by itself explain why our from-scratch minimal repros (no pre-existing file on either side) passed 100% reliably on local Docker Desktop but failed 100% reliably on GitHub Actions/Render. That would need something environment-specific happening after this point — e.g. a difference in when Publish's own separate asset-resolution pass touches things again, or an MSBuild evaluation-cache detail — that I haven't traced into the source. Flagging it in case it's a useful thread for someone closer to this code to pull on.

[Popl7]

Filed the dotnet/sdk-side issue with the source-level root cause and full repro links: dotnet/sdk#55883