microsoft / microsoft/aspire

PublishAsMigrationBundle(publishContainer: true) defaults to a base image missing Microsoft.AspNetCore.App, crashing the container for Web SDK target projects

Open
#18,830 1 comment 0 reactions 0 assignees View on GitHub
area-integrations entityframework triage:bot-seen
Dominant language
C#
Stars
6.3k
Forks
991
Avg merge
2d 15h
Merged PRs (30d)
196

Description

### Is there an existing issue for this?
- [x] I have searched the existing issues (related but distinct: #18767, #18805, #17847 — same general area, different symptoms)

### Describe the bug

When the migrations target project (the one containing the `DbContext`) is a `Microsoft.NET.Sdk.Web` project, the container image generated by `.PublishAsMigrationBundle(publishContainer: true)` crashes on startup because it's missing the `Microsoft.AspNetCore.App` shared framework.

The generated Dockerfile uses `mcr.microsoft.com/dotnet/runtime:10.0` as its base image (Aspire's default when no `baseImage` is specified). That image only includes `Microsoft.NETCore.App` — but the compiled `efbundle` executable needs to load the target project's assembly to discover the `DbContext` via reflection/design-time services, and a `Microsoft.NET.Sdk.Web` project's assembly requires `Microsoft.AspNetCore.App` just to load, regardless of whether the DbContext code itself uses any ASP.NET Core APIs.

This is a very common project layout (DbContext living directly in the API project rather than a separate class library), so I'd expect this to affect most people who haven't split their `DbContext` into its own non-Web project.

### Expected Behavior

Either:
- Aspire detects that the target project's `TargetFramework`/SDK requires `Microsoft.AspNetCore.App` and picks an appropriate default base image automatically, or
- The docs for `PublishAsMigrationBundle`/`AddEFMigrations` call out this requirement explicitly and explain how to override `baseImage`.

### Actual behavior

The container starts and immediately exits with:

```
App: /app/efbundle
Architecture: x64
Framework: 'Microsoft.AspNetCore.App', version '10.0.0' (x64)
.NET location: /usr/share/dotnet

No frameworks were found.

Learn more:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=10.0.0&arch=x64&rid=linux-x64&os=ubuntu.24.04

You must install or update .NET to run this application.
```

When deployed as an Azure Container App Job, this shows up simply as execution status `Failed` — the actual error above is only visible by digging into the container's own logs (e.g. via Log Analytics), not surfaced anywhere in the `aspire publish`/deploy output.

### Steps To Reproduce

1. Create an ASP.NET Core Web API project (`Microsoft.NET.Sdk.Web`) with an EF Core `DbContext` defined directly in that project (not a separate class library).
2. In the AppHost:
```csharp
var db = builder.AddPostgres("pg").AddDatabase("appdb");

var api = builder.AddProject("api")
.WithReference(db);

var apiMigrations = api.AddEFMigrations("api-migrations")
.WithReference(db)
.WaitFor(db)
.PublishAsMigrationBundle(publishContainer: true)
.PublishAsAzureContainerAppJob();
```
3. `aspire publish` (or deploy to Azure Container Apps).
4. Run the generated `api-migrations` container/job — it exits immediately with the error above.

### Workaround

Pass `baseImage` explicitly:

```csharp
.PublishAsMigrationBundle(publishContainer: true, baseImage: "mcr.microsoft.com/dotnet/aspnet:10.0")
```

Note: the auto-generated Dockerfile's `ENTRYPOINT` is shell-form (it expands a connection-string env var), so the `-chiseled` image variants (which ship without `/bin/sh`) don't work as a substitute — they fail even earlier, with an opaque `exec: "/bin/sh": stat /bin/sh: no such file or directory` from the container runtime itself.

### Environment

- Aspire.AppHost.Sdk: 13.4.6
- Aspire.Hosting.EntityFrameworkCore: 13.4.6-preview.1.26319.6
- .NET SDK: 10.0
- Target: Azure Container Apps (`PublishAsAzureContainerAppJob`)

Contributor guide

Open the contributing guide

Research direction

Start with PublishAsMigrationBundle and AddEFMigrations, then reproduce the generated container using a Microsoft.NET.Sdk.Web project and inspect its Dockerfile and base image. Done means the generated migration bundle runs without manually supplying baseImage, or the relevant documentation clearly explains the Microsoft.AspNetCore.App requirement and override.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, csharp, docker
Domain
cloud, devops
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.