Verwendung eines separaten Migrationsprojekts

Sie können Migrationen in einem anderen Projekt speichern als das, das Ihre DbContextEnthält. Dies wird empfohlen, wenn das Anwendungsprojekt plattformspezifisch ist, z. B. WinUI, .NET MAUI, Blazor WebAssembly oder Azure Functions oder wenn es auf einen bestimmten Laufzeitbezeichner (RID) abzielt. Sie kann auch verwendet werden, um mehr als eine Gruppe von Migrationen zu verwalten.

Projektlayout

Im Beispiel werden drei Projekte verwendet:

Die Anwendung benötigt einen Verweis auf das Migrationsprojekt, wenn sie Migrationen zur Laufzeit erkennt oder anwendet, z. B. durch Aufrufen Migrate. Wenn Migrationen nur von einem Bereitstellungsartefakt angewendet werden und die Anwendung sie nie lädt, ist dieser Verweis nicht erforderlich.

Konfigurieren der Projekte

1. Erstellen Sie eine Klassenbibliothek für die Migrationen, und fügen Sie einen Verweis auf das Projekt hinzu, das das DbContextProjekt enthält.

2. Fügen Sie den Datenbankanbieter und Microsoft.EntityFrameworkCore.Design dem Migrationsprojekt hinzu. Kennzeichnen des Designpakets als private Entwicklungsabhängigkeit:

   <ItemGroup>
     <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="...">
       <PrivateAssets>all</PrivateAssets>
       <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
     </PackageReference>
     <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="..." />
   </ItemGroup>
   
   <ItemGroup>
     <ProjectReference Include="..\WebApplication1.Data\WebApplication1.Data.csproj" />
   </ItemGroup>
   

3. Implementieren IDesignTimeDbContextFactory<TContext> sie im Migrationsprojekt. Die Factory ermöglicht es den Tools, den Kontext zu erstellen, ohne das Anwendungsprojekt auszuführen:

   public class ApplicationDbContextFactory : IDesignTimeDbContextFactory<ApplicationDbContext>
   {
       public ApplicationDbContext CreateDbContext(string[] args)
       {
           var connectionString = args.FirstOrDefault()
               ?? @"Server=(localdb)\mssqllocaldb;Database=WebApplication1;Trusted_Connection=True";
   
           var options = new DbContextOptionsBuilder<ApplicationDbContext>()
               .UseSqlServer(
                   connectionString,
                   sqlServer => sqlServer.MigrationsAssembly(typeof(ApplicationDbContextFactory).Assembly.GetName().Name))
               .Options;
   
           return new ApplicationDbContext(options);
       }
   }
   

   Halten Sie die Entwurfszeitanbieter- und Modellkonfiguration konsistent mit der Laufzeitkonfiguration. Das Beispiel akzeptiert ein optionales Verbindungszeichenfolge-Argument und verwendet eine lokale Entwicklungsverbindung, wenn kein Argument angegeben wird.

4. Konfigurieren Sie die Migrationsassembly beim Registrieren des Kontexts zur Laufzeit:

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

5. Wenn die Anwendung Migrationen anwendet oder diese zur Laufzeit auf andere Weise erkennt, fügen Sie dem Migrationsprojekt einen normalen Verweis aus der Anwendung hinzu:

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

   Das Datenprojekt darf nicht auf das Migrationsprojekt verweisen. Dies würde eine Zirkelabhängigkeit erstellen, da das Migrationsprojekt bereits auf das Datenprojekt verweist.

6. Wenn Migrationen bereits vorhanden sind, verschieben Sie alle Migrationsdateien und die Modellmomentaufnahme in das Migrationsprojekt, und aktualisieren Sie ihre Namespaces. Wenn keine Migrationen vorhanden sind, kann die Entwurfszeitfactory die anfängliche Migration direkt im Migrationsprojekt erstellen.

Verwenden der Tools

Verwenden Sie das Migrationsprojekt sowohl als Zielprojekt als auch als Startprojekt. Das Zielprojekt empfängt generierte Dateien, während das Startprojekt von den Tools erstellt und ausgeführt wird. In diesem Layout verhindert die Verwendung des Migrationsprojekts für beide, dass die Tools den Anwendungsstartcode ausführen.

dotnet ef migrations add NewMigration \
    --project WebApplication1.Migrations \
    --startup-project WebApplication1.Migrations

dotnet ef migrations list \
    --project WebApplication1.Migrations \
    --startup-project WebApplication1.Migrations

dotnet ef migrations script --output artifacts/migrations.sql \
    --project WebApplication1.Migrations \
    --startup-project WebApplication1.Migrations

dotnet ef migrations bundle --output artifacts/efbundle \
    --project WebApplication1.Migrations \
    --startup-project WebApplication1.Migrations

Add-Migration NewMigration `
    -Project WebApplication1.Migrations `
    -StartupProject WebApplication1.Migrations

Erstellen Sie das Migrationsprojekt, bevor Sie Befehle mit --no-buildoder bevor ein anderer Prozess seine Ausgabe verwendet. Ein normaler dotnet ef Befehl erstellt automatisch die Ziel- und Startprojekte.

Plattformspezifische Anwendungen

Verwenden Sie kein plattformspezifisches Anwendungsprojekt als Startprojekt für EF-Tools. Mobile, Browser, Desktop, Funktionen und RID-spezifische Projekte können eine Workload oder einen nativen Host erfordern, der dotnet ef nicht ausgeführt werden kann. Ab EF Core 11 warnen die Tools, wenn ein plattformspezifisches Startprojekt verwendet wird.

Verwenden Sie das oben beschriebene Layout für .NET MAUI, WinUI, Blazor WebAssembly, Azure Functions und ähnliche Anwendungen:

1. Fügen Sie die Kontext- und Entitätstypen in ein freigegebenes Datenprojekt ein.
2. Platzieren Sie Migrationen und IDesignTimeDbContextFactory<TContext> in einem normalen plattformübergreifenden .NET Projekt.
3. Führen Sie die Tools mit dem Migrationsprojekt als Ziel- und Startprojekt aus.
4. Verweisen Sie auf das Migrationsprojekt aus der Anwendung nur, wenn die Anwendung migrationen zur Laufzeit lädt oder anwendet.

Direkte Toolunterstützung für Xamarin- und MAUI-Plattformprojekte ist nicht geplant; siehe dotnet/efcore#7152. Xamarin Anwendungen sollten zuerst auf .NET MAUI aktualisiert werden.

Prozessarchitektur

Der Prozess, der die Tools ausführt, muss in der Lage sein, jede Entwurfszeitassembly zu laden. Ein 64-Bit-Visual Studio- oder .NET-Prozess kann keine nur x86-Startassembly laden, und die gleiche Einschränkung gilt für Arm64 und andere Architekturen. Bevorzugen Sie ein AnyCPU-Migrationsprojekt. Wenn Entwurfszeitabhängigkeiten eine bestimmte Architektur erfordern, rufen Sie explizit einen übereinstimmenden .NET SDK auf.

Die Entwurfszeitprozessarchitektur unterscheidet sich vom Bereitstellungsziel. Verwenden oder -TargetRuntime generieren Sie beim Erstellen eines Bundles --target-runtime ein Artefakt für die Bereitstellung RID, zlinux-arm64. B. oder osx-arm64.