Repository navigation
PublishWithContainerFiles + ASP.NET Core Static Assets #19768
Description
Activity
I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):
MihuBot (not a human) (@MihuBot) potentially something to watch when implementation a fix, but not a duplicate. AFAICT Aspire doesn't even try to make FE assets availible to the BE build - it just includes both in the generated container.
🤖 Aspire triage pass — 2026-08-28 08:07 UTC
Area:
area-polyglot,area-deployment
Kind: feature-request
Repro: partial — scenario described in the "problem" section (no minimal repro project)
Affected version(s): not specified in body (latest: 13.5 line shipped; 13.6 in progress)
Severity: S3 — static assets published into the container image skip ASP.NET Core build-time fingerprinting/compression (no etags, uncompressed); app still runs, manual workaround likely existsUrgency: ⚪ backlog — no milestone
Reason: feature request / enhancement (ordering of container-files copy vs. backend static-asset processing); not a regression and not S1/S2Suggested owner(s): Sébastien Ros (@sebastienros) (polyglot/JS lead), backup Mitch Denny (@mitchdenny) (container-files publish)
Evidence:- sebastienros closed many
area-polyglotissues as completed (Aspire TS + Orleans - Argument of type 'OrleansService' is not assignable to parameter of type 'OrleansServiceClientHandle' #17666, Export TypeScript ATS metadata for documented AppHost APIs #17875, [TypeScript AppHost] Expose WithContainerBuildOptions / ContainerTargetPlatform for cross-architecture container builds #17939, Add a warning and migration path from apphost.ts to apphost.mts #17842, TypeScript AppHost fails code generation with 13.4.3 CLI and 13.5 daily SDK #18110, ASPIREEXPORT001 flagging 'extension' keyword-based extension methods as invalid #17604, Polyglot withHttpEndpointCallback / withEndpointCallback deadlocks when callback body performs nested RPC mutation #17391, Experimentally publish Aspire.Hosting.Integration.Analyzers for integration developers #17264,aspire updatefor TypeScript AppHost fails with "No code generator found for language: TypeScript" when CLI is older than target package version; leaves project in broken state #17077, Add TypeScript parity for aspire.dev AppHost snippets #17047) and closedarea-deploymentWithComputeEnvironment isn't exposed to Polyglot #17085 - mitchdenny owns
area-deploymentcontainer/publish work: merged Fix Kubernetes hostname publishing and routing #19430, Fix Kubernetes values for embedded environment parameters #19429, Set a default fsGroup for Kubernetes persistent volumes #19374, Add first-class KubernetesPersistentVolumeResource (and fix related YAML serializer bugs) #16929; closed TLS FQDN discovery waits 15 minutes for skipped route-less Gateway #19217, AKS credential pipeline uses ambient Azure CLI subscription #19216, AddPersistentVolume cannot be used with AzureKubernetesEnvironmentResource #19210, [Failing test]: Aspire.Deployment.EndToEnd.Tests.AzureResourceScopeDeploymentTests.DeployExistingServiceBusWithResourceGroupAndSubscriptionScope #19173, Deployment E2E: AKS/Kubernetes tests fail due to Azure compute quota/capacity in centralus #18933 as completed
Confidence: medium
Needs human?: no- sebastienros closed many
Probably related to #17563.
It seems like the current extensibility points don't really allow connecting container builds together.
I guess the work around is to use esproj for deployment leaving
AddViteAppfor debugging or just live without angular dev server console output in the dashboard 😢.
Is your feature request related to a problem? Please describe the problem.
PublishWithContainerFiles(with eg.AddViteAppfor the "Static frontend served by a backend"), copies files after the backend build has completed.This means that ASP.NET Core's "Static Asset" build time compression and fingerprinting doesn't include those files.
The means my static assets don't have etags and aren't compressed unless I do something (I haven't worked out exactly what yet). This should work out of the box.
Describe the solution you'd like
Simplest would be to delay the backend build until after the front end files are copied. Not ideal.
Better would be for the fingerprinting and compression process to run as part of the copy to the container image process. Alternatively add the right dependencies to the backend build so that it waits if needed and everything continues in parallel if possible.
Maybe at least add some docs.