Postgres/SQL Server EF components make it hard to run `dotnet ef` to create migrations, etc.

[DamianEdwards]

Because the PostgreSQL and SQL Server EF components cause the app to fail on startup if the specified connection string isn't found in configuration, and that configuration is usually set by the AppHost project when running in the inner loop, you can't easily run dotnet ef to create a new migration, etc., as the dotnet ef actually runs the app in order to get a handle on the built host and container so it can interact with the DbContext.

We'll need to think about how to unblock this scenario.

[mitchdenny]

Realistically people that need to do EF migrations should probably put them into a worker project so they can constrain what process has rights to update DB schema.

[davidfowl]

What if we let you run commands in the context of an orchestrated project. The idea here is to model what you would do when you wanted to run a command inside of a container.

docker --entrypoint dotnet run myapi ef database migrate

The command looks funny but it lets you run the dotnet ef command inside of the myapi container. Consider the equivalent here being run the migration command in the context of a project (that way it has all of the needed environment). You would enter a command line to run and specify which project to target. This would clone all of the environment of that executable and change the entry point to your command line.

[mitchdenny]

So AddExecutable might take a container/project resource builder as a baseline.

[mitchdenny]

I think we can close this right? Out advice is to have another service that manages these db migrations?

[davidfowl]

Not sure, we need more discussion with the ef team. Manually adding migrations is also a pain.

[mitchdenny]

Ah true, I was thinking more about running migrations not creating the snapshots.

[analogrelay]

This is basically the first issue that came up when I was playing with Aspire this weekend.

A couple ideas come to mind here:

In past projects, I've found it useful to keep "support" containers like databases running constantly in the background. That allows connecting tools like DataGrip for querying the database, and allows for running migrations, etc. It feels like it'd be useful to have a way to keep those containers running during development, even as the app you're working on is shutdown and restarted several times. Docker Compose has "profiles" which I've used for this in the past

The default behavior for AddPostgresContainer generates a random password each time. It feels like Aspire could leverage user-secrets here. In my app I generated my own db password and stored it in user secrets for the AppHost, then retrieved that value in Program.cs to pass to AddPostgresContainer. Then, I used a fixed db port number so I could connect as needed, for running migrations, using query/analysis tools, etc. It seems to me, some of that flow could be automated.

Some kind of command line tool might be useful here. The command aspire run --reference postgres -- dotnet ef ... command would create an ephemeral resource that references the postgres resource (thus getting env vars for it) and immediately run it.

[mitchdenny]

@DamianEdwards @davidfowl @karolz-ms ... the idea of persistent background containers is interesting. I think it would require some coordination between AppHost and DCP to do it right.

I think we'd still want containers to be emphemeral by default but with an AppHost API guesture we could mark them as being "potentially persistent". By potentially persistent, I mean if a container is marked to be retained after shutdown DCP would leave it alone, and then based on some criterial, DCP wouldn't attempt to recreate the container if it was already running.

How AppHost/DCP determines whether a container is suitable to be reused would be interesting. I'm thinking computing some hash of the definition of the container (so if password and bindings were stable it could be reused).

All that said ... @analogrelay - if your goal is to connect tools like DataGrip, you can actually set a persistent password and port for your Postgres container.

var postgres = builder.AddPostgresContainer("postgres", password: "knockknock!", port: 1234);

I should add that I think the pattern we've used in some of our samples around having a support container do database migrations is the better pattern than worrying about running dotnet ef migrate as it neatly solves the problem of how you handle migrations from app code in production.

[rcollina]

I thought I'd chime in, I've also been using persistent containers, which is something I'd love to see supported.
Developers have their own local dev env codified in a relatively simple Docker Compose file.