Using a Separate Migrations Project
You may want to store your migrations in a different project than the one containing your DbContext
. You can also use this strategy to maintain multiple sets of migrations, for example, one for development and another for release-to-release upgrades.
Tip
You can view this article's sample on GitHub.
Steps
Create a new class library.
Add a reference to your DbContext project.
Move the migrations and model snapshot files to the class library.
Tip
If you have no existing migrations, generate one in the project containing the DbContext then move it. This is important because if the migrations project does not contain an existing migration, the Add-Migration command will be unable to find the DbContext.
Configure the migrations assembly:
services.AddDbContext<ApplicationDbContext>( options => options.UseSqlServer( Configuration.GetConnectionString("DefaultConnection"), x => x.MigrationsAssembly("WebApplication1.Migrations")));
Add a reference to your migrations project from the startup project.
<ItemGroup> <ProjectReference Include="..\WebApplication1.Migrations\WebApplication1.Migrations.csproj" /> </ItemGroup>
If this causes a circular dependency, you can update the base output path of the migrations project instead:
<PropertyGroup> <BaseOutputPath>..\WebApplication1\bin\</BaseOutputPath> </PropertyGroup>
If you did everything correctly, you should be able to add new migrations to the project.
dotnet ef migrations add NewMigration --project WebApplication1.Migrations
Σχόλια
https://aka.ms/ContentUserFeedback.
Σύντομα διαθέσιμα: Καθ' όλη τη διάρκεια του 2024 θα καταργήσουμε σταδιακά τα ζητήματα GitHub ως μηχανισμό ανάδρασης για το περιεχόμενο και θα το αντικαταστήσουμε με ένα νέο σύστημα ανάδρασης. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα:Υποβολή και προβολή σχολίων για