Improve Migrations Projects

[bricelam]

Today, a lot of people end up deploying all of their migrations with their app. If they're applying those migrations as part of deployment, they just sit there taking up space.

We could introduce a new kind of project just for migrations. After creating the project, calling dotnet ef migrations add would add new migrations to this separate project keeping them out of your app. The result of building this project could even be a migrations bundle (see #19693).

[bricelam]

Open design questions:

• How do we configure the migrations assembly?
  • Users would need to select the context/startup assembly in the new project wizard
    • We'd need to add a reference between the projects
    • We'd need to configure the migrations assembly
      • We could us Roslyn to modify OnConifuring/AddDbContext
      • We could add an assembly-level attribute to the DbContext project
  • Add-Migration might need some changes
    • Invoking it on either project should only add files to the migrations project
    • How do we find the DbContext from the migrations project on the first migration? A new assembly-level attribute could work

[glen-84]

How does this differ from Using a Separate Migrations Project?

[bricelam]

@glen-84 It's basically just adding conventions, sugar, and better tooling to make that easier.

[AndriySvyryd]

With some additional work migrations projects can integrate well with Aspire.

However, there's currently no good way of creating a development dependency on a project, tracked by NuGet/Home#10907