Add a hosting integration for the `dotnet ef` global tool

[DamianEdwards]

Create a new hosting integration that provides integration with the dotnet ef global tool.

Package name: Aspire.Hosting.dotnet-ef
Assembly name: Aspire.Hosting.DotnetEf

High-level feature outline

This isn't intended to be a final spec. Details should be discussed and iterated on as part of implementation and the shape and/or set of functionality may change:

• Top-level resource for adding functionality associated with dotnet ef, e.g.: builder.AddDotnetEf("dotnet-ef");
• Support for auto-acquiring the dotnet-ef tool package if not already installed (options for global vs. local install, default to install local if required version not already installed globally?)
• Support for producing migration scripts and/or migration bundles as part of publishing the AppHost, e.g. .PublishAsMigrationScript()
• Support for running migrations on AppHost start and having other resources wait on the migrations to complete, e.g.:

  var ef = builder.AddDotnetEf("dotnet-ef");
  var api = builder.AddProject<Api>("api");
  var apiMigrations = api.AddEfMigrations("api-migrations", ef).RunDatabaseUpdateOnStart();

• Adds resource commands for dotnet ef to resources that AddEfMigrations was called on:
  • "Update database": Runs the dotnet ef database update command on the resource
  • "Drop database": Runs the dotnet ef database drop command on the resource
  • "Reset database": Runs dotnet ef database drop followed by dotnet ef database update on the resource
  • "Add migration...": Prompts for a migration name (and some options from dotnet ef migrations add) before running dotnet ef migrations add <NAME> on the resource. If the resource is not stopped, we should pass the --no-build option.
  • "Remove migration": Runs dotnet ef migrations remove on the resource to remove the last migration
  • "Remove migration (force)": Prompts for confirmation and then runs dotnet ef migrations remove -force on the resource to remove the last migration and revert it from the database

[afscrome]

Support for auto-acquiring the dotnet-ef

Could this include making a more generic dotnet tool resource type that the EF resource could be built on, with the tool resource handling the tool acquisition - I have some other uses cases where I could make use of that portion.

[SackMaggie]

Would love to have this implemented, Right now there are so many steps involve before db migrations can be done.
When this #10301 done, Some form of db backup could be integrated (e.g. running pg_dump into volume!)

I know it mainly for development, but a backup is a backup (chore)

[DamianEdwards]

Could this include making a more generic dotnet tool resource type that the EF resource could be built on, with the tool resource handling the tool acquisition - I have some other uses cases where I could make use of that portion.

Yep, although we can always factor that out later.

[willdean]

Sounds like a good idea, now that I've finished writing a separate migration project. :-)

Please don't forget to consider the use-case of solutions which have multiple DbContetxt types, in multiple libraries. (i.e. those of us who never run dotnet ef without also including --startup-project and --context options)

[DamianEdwards]

Please don't forget to consider the use-case of solutions which have multiple DbContetxt types, in multiple libraries. (i.e. those of us who never run dotnet ef without also including --startup-project and --context options)

Yep good point. I don't think --startup-project will be required as you'll only add app projects to the AppHost model, but for sure the --context option will need to be supported to allow for differentiating between multiple DbContext types.

[afscrome]

With DotnetToolResource added in 13.2, the acquisition can now be handled by that.