Używanie oddzielnego projektu migracji

Migracje można przechowywać w innym projekcie niż ten zawierający element DbContext. Jest to zalecane, gdy projekt aplikacji jest specyficzny dla platformy, taki jak WinUI, .NET MAUI, Blazor WebAssembly lub Azure Functions lub gdy jest przeznaczony dla określonego identyfikatora środowiska uruchomieniowego (RID). Może również służyć do obsługi więcej niż jednego zestawu migracji.

Tip

Możesz wyświetlić przykład tego artykułu w GitHub.

Układ projektu

W przykładzie są używane trzy projekty:

Projekt	Odpowiedzialność	References
`WebApplication1.Data`	Jest właścicielem `DbContext` typów jednostek i	Dostawca programu EF Core
`WebApplication1.Migrations`	Jest właścicielem migracji, migawki modelu i tworzenia kontekstu w czasie projektowania	Projekt danych, dostawca platformy EF Core i `Microsoft.EntityFrameworkCore.Design`
`WebApplication1`	Uruchamia aplikację	Projekt projektu i migracji danych

Aplikacja potrzebuje odwołania do projektu migracji, gdy odnajduje lub stosuje migracje w czasie wykonywania, na przykład przez wywołanie metody Migrate. Jeśli migracje są stosowane tylko przez artefakt wdrożenia, a aplikacja nigdy ich nie ładuje, odwołanie nie jest wymagane.

Konfigurowanie projektów

Utwórz bibliotekę klas dla migracji i dodaj odwołanie do projektu zawierającego element DbContext.

Dodaj dostawcę bazy danych i Microsoft.EntityFrameworkCore.Design do projektu migracji. Oznacz pakiet projektowy jako zależność od prywatnego programowania:

<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>

Zaimplementuj IDesignTimeDbContextFactory<TContext> projekt migracji. Fabryka umożliwia narzędziom tworzenie kontekstu bez uruchamiania projektu aplikacji:

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);
    }
}

Zachowaj spójność dostawcy czasu projektowania i konfiguracji modelu z konfiguracją środowiska uruchomieniowego. Przykład akceptuje opcjonalny argument parametry połączenia i używa lokalnego połączenia programistycznego, gdy nie podano żadnego argumentu.

Skonfiguruj zestaw migracji podczas rejestrowania kontekstu w czasie wykonywania:

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

Jeśli aplikacja stosuje migracje lub w inny sposób odnajduje je w czasie wykonywania, dodaj normalne odwołanie z aplikacji do projektu migracji:
```
<ItemGroup>
  <ProjectReference Include="..\WebApplication1.Migrations\WebApplication1.Migrations.csproj" />
</ItemGroup>
```
Projekt danych nie może odwoływać się do projektu migracji. Spowodowałoby to utworzenie zależności cyklicznej, ponieważ projekt migracji już odwołuje się do projektu danych.
Jeśli migracje już istnieją, przenieś wszystkie pliki migracji i migawkę modelu do projektu migracji i zaktualizuj ich przestrzenie nazw. Jeśli nie ma istniejących migracji, fabryka czasu projektowania umożliwia utworzenie początkowej migracji bezpośrednio w projekcie migracji.

Korzystanie z narzędzi

Użyj projektu migracji zarówno jako projektu docelowego, jak i projektu startowego. Projekt docelowy otrzymuje wygenerowane pliki, podczas gdy projekt startowy jest kompilowany i wykonywany przez narzędzia. W tym układzie użycie projektu migracji dla obu elementów uniemożliwia narzędziom wykonywanie kodu uruchamiania aplikacji.

interfejs wiersza polecenia .NET CLI
Visual Studio

Uruchom następujące polecenia z katalogu rozwiązania:

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

Te same opcje projektu dotyczą innych poleceń:

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

Począwszy od programu EF Core 11, wielokrotne opcje projektu można przechowywać w programie .config/dotnet-ef.json.

Użyj project migracji dla systemów -Project i -StartupProject:

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

Te same parametry można przekazać do Get-Migrationpoleceń , , Bundle-MigrationScript-Migrationi innych Menedżer pakietów Konsoli.

Skompiluj projekt migracji przed uruchomieniem poleceń za pomocą --no-buildpolecenia lub przed użyciem danych wyjściowych przez inny proces. Normalne dotnet ef polecenie automatycznie kompiluje projekty docelowe i startowe.

Aplikacje specyficzne dla platformy

Nie używaj projektu aplikacji specyficznego dla platformy jako projektu startowego dla narzędzi EF. Projekty dla urządzeń przenośnych, przeglądarek, komputerów stacjonarnych, funkcji i identyfikatorów RID mogą wymagać obciążenia lub hosta natywnego, który dotnet ef nie może być wykonywany. Począwszy od programu EF Core 11, narzędzia ostrzegają, gdy jest używany projekt startowy specyficzny dla platformy.

Użyj układu opisanego powyżej dla .NET MAUI, WinUI, Blazor WebAssembly, Azure Functions i podobnych aplikacji:

Umieść kontekst i typy jednostek w udostępnionym projekcie danych.
Umieść migracje i IDesignTimeDbContextFactory<TContext> w normalnym projekcie .NET międzyplatformowych.
Uruchom narzędzia z projektem migracji jako projekt docelowy i startowy.
Odwołaj się do projektu migracji z aplikacji tylko wtedy, gdy aplikacja ładuje lub stosuje migracje w czasie wykonywania.

Bezpośrednia obsługa narzędzi dla projektów platformy Xamarin i MAUI nie jest planowana. Zobacz dotnet/efcore#7152. Xamarin aplikacje należy najpierw uaktualnić do .NET MAUI.

Architektura procesu

Proces uruchamiania narzędzi musi być w stanie załadować każdy zestaw w czasie projektowania. 64-bitowy Visual Studio lub proces .NET nie może załadować zestawu uruchamiania tylko x86, a to samo ograniczenie dotyczy usługi Arm64 i innych architektur. Preferuj projekt migracji platformy AnyCPU. Jeśli zależności czasu projektowania wymagają określonej architektury, wywołaj jawnie pasujący zestaw SDK .NET.

Architektura procesu w czasie projektowania jest oddzielona od celu wdrożenia. Podczas tworzenia pakietu użyj --target-runtime lub -TargetRuntime wygeneruj artefakt dla identyfikatora RID wdrożenia, takiego jak linux-arm64 lub osx-arm64.

Opinia

Czy ta strona była pomocna?

Last updated on 2026-08-13