Uso de um Projeto de Migrações Separado

Pode armazenar migrações num projeto diferente daquele que contém o seu DbContextarquivo . Isto é recomendado quando o projeto de aplicação é específico de uma plataforma, como WinUI, .NET MAUI, Blazor WebAssembly ou Funções do Azure, ou quando tem como alvo um identificador de runtime (RID) específico. Também pode ser usado para manter mais do que um conjunto de migrações.

Estrutura do projeto

O exemplo utiliza três projetos:

A aplicação precisa de uma referência ao projeto de migrações quando descobre ou aplica migrações em tempo de execução, por exemplo, chamando Migrate. Se as migrações forem aplicadas apenas por um artefacto de implementação e a aplicação nunca as carregar, essa referência não é necessária.

Configurar os projetos

1. Crie uma biblioteca de classes para as migrações e adicione uma referência ao projeto que contenha o DbContext.

2. Adicione o fornecedor da base de dados e Microsoft.EntityFrameworkCore.Design ao projeto de migrações. Marque o pacote de design como uma dependência de desenvolvimento privado:

   <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. Implementa IDesignTimeDbContextFactory<TContext> no projeto de migrações. A fábrica permite que as ferramentas criem o contexto sem executar o projeto de aplicação:

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

   Mantenha a configuração do fornecedor e modelo em tempo de projeto consistente com a configuração em tempo de execução. O exemplo aceita um argumento opcional de cadeia de ligação e utiliza uma ligação de desenvolvimento local quando não é fornecido argumento.

4. Configure o assembly das migrações ao registar o contexto em tempo de execução:

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

5. Se a aplicação aplicar migrações ou as descobrir em tempo de execução, adicione uma referência normal da aplicação ao projeto de migrações:

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

   O projeto de dados não deve referenciar o projeto de migrações. Isso criaria uma dependência circular porque o projeto de migrações já faz referência ao projeto de dados.

6. Se as migrações já existirem, move todos os ficheiros de migração e o snapshot do modelo para o projeto de migrações e atualiza os seus namespaces. Quando não existem migrações existentes, a fábrica de tempo de design permite que a migração inicial seja criada diretamente no projeto de migrações.

Utilize as ferramentas

Usa o projeto de migrações como projeto-alvo e projeto inicial. O projeto-alvo recebe ficheiros gerados, enquanto o projeto inicial é construído e executado pelas ferramentas. Neste layout, usar o projeto de migrações para ambos impede que as ferramentas executem código de arranque de aplicações.

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

Construa o projeto de migrações antes de executar comandos com --no-build, ou antes de outro processo consumir a sua saída. Um comando normal dotnet ef constrói automaticamente o projeto alvo e de arranque.

Aplicações específicas de plataforma

Não uses um projeto de aplicação específico da plataforma como projeto inicial para ferramentas de EF. Projetos móveis, browser, desktop, funcionais e específicos de RID podem exigir uma carga de trabalho ou um host nativo que dotnet ef não consiga ser executado. A partir do EF Core 11, as ferramentas avisam quando é utilizado um projeto de arranque específico da plataforma.

Use o layout descrito acima para .NET MAUI, WinUI, Blazor WebAssembly, Funções do Azure e aplicações semelhantes:

1. Coloque o contexto e os tipos de entidade num projeto de dados partilhados.
2. Coloca migrações num IDesignTimeDbContextFactory<TContext> projeto .NET multiplataforma normal.
3. Executa as ferramentas com o projeto de migrações como alvo e projeto inicial.
4. Consulte o projeto de migrações a partir da aplicação apenas se a aplicação carregar ou aplicar migrações em tempo de execução.

O suporte direto de ferramentas para projetos de plataformas Xamarin e MAUI não está planeado; veja dotnet/efcore#7152. As aplicações Xamarin devem primeiro ser atualizadas para .NET MAUI.

Arquitetura de processo

O processo que executa as ferramentas deve ser capaz de carregar todas as montagens em tempo de projeto. Um processo Visual Studio ou .NET de 64 bits não consegue carregar um assembly de arranque apenas x86, e a mesma restrição aplica-se ao Arm64 e a outras arquiteturas. Prefiro um projeto de migração AnyCPU. Se as dependências em tempo de design exigirem uma arquitetura específica, invoque explicitamente um SDK .NET correspondente.

A arquitetura do processo em tempo de conceção é separada do alvo de implementação. Ao criar um bundle, use --target-runtime ou -TargetRuntime para gerar um artefacto para o RID de implementação, como linux-arm64 ou osx-arm64.