Uso di un progetto di migrazioni separato

  • Articolo

È possibile archiviare le migrazioni in un progetto diverso da quello contenente DbContext. È anche possibile usare questa strategia per gestire più set di migrazioni, ad esempio uno per lo sviluppo e un altro per gli aggiornamenti da rilascio a versione.

Suggerimento

È possibile visualizzare l'esempio di questo articolo in GitHub.

Passaggi

  1. Creare una nuova libreria di classi.

  2. Aggiungere un riferimento al progetto DbContext.

  3. Spostare le migrazioni e i file di snapshot del modello nella libreria di classi.

    Suggerimento

    Se non sono presenti migrazioni, generarne una nel progetto contenente DbContext, quindi spostarla. Questo aspetto è importante perché se il progetto di migrazioni non contiene una migrazione esistente, il comando Add-Migration non sarà in grado di trovare DbContext.

  4. Configurare l'assembly delle migrazioni:

    services.AddDbContext<ApplicationDbContext>(
    options =>
        options.UseSqlServer(
            Configuration.GetConnectionString("DefaultConnection"),
            x => x.MigrationsAssembly("WebApplication1.Migrations")));

  5. Aggiungere un riferimento al progetto di migrazioni dal progetto di avvio .

    <ItemGroup>
  <ProjectReference Include="..\WebApplication1.Migrations\WebApplication1.Migrations.csproj" />
</ItemGroup>

    Se questa causa una dipendenza circolare, è possibile aggiornare invece il percorso di output di base del progetto di migrazioni :

    <PropertyGroup>
  <BaseOutputPath>..\WebApplication1\bin\</BaseOutputPath>
</PropertyGroup>

Se l'operazione è stata eseguita correttamente, sarà possibile aggiungere nuove migrazioni al progetto.

dotnet ef migrations add NewMigration --project WebApplication1.Migrations