Як увімкнути міграцію EF для кількох контекстів для розділення баз даних?

Як увімкнути міграцію Entity Framework 5 (версія 5.0.0) для кількох контекстів БД в одному проекті, де кожен контекст відповідає власній базі даних? Коли я запускаю Enable-Migrationsв консолі PM (Visual Studio 2012), виникає помилка через те, що існує декілька контекстів:

PM> Enable-Migrations
More than one context type was found in the assembly 'DatabaseService'.
To enable migrations for DatabaseService.Models.Product1DbContext, use Enable-Migrations -ContextTypeName DatabaseService.Models.Product1DbContext.
To enable migrations for DatabaseService.Models.Product2DbContext, use Enable-Migrations -ContextTypeName DatabaseService.Models.Product2DbContext.

Якщо я запускаю, Enable-Migrations -ContextTypeName DatabaseService.Models.Product1DbContextмені не дозволяється запускатись, Enable-Migrations -ContextTypeName DatabaseService.Models.Product2DbContextоскільки міграція вже існує:Migrations have already been enabled in project 'DatabaseService'. To overwrite the existing migrations configuration, use the -Force parameter.

2-й виклик Enable-Migrations провалюється, оскільки файл Configuration.cs вже існує. Якщо ви перейменовуєте цей клас і файл, ви зможете запустити цей 2-й увімкнено-міграційний процес, який створить інший Configuration.cs.

Потім вам потрібно буде вказати, яку конфігурацію ви хочете використовувати під час оновлення баз даних.

Update-Database -ConfigurationTypeName MyRenamedConfiguration

На додаток до того, що @ckal запропонував, важливо надати кожному перейменованому Configuration.cs свій простір імен. Якщо цього не зробити, EF спробує застосувати міграцію до неправильного контексту.

Ось конкретні кроки, які добре працюють для мене.

Якщо міграція переплутана, і ви хочете створити нову "базову лінію":

1. Видаліть усі існуючі файли .cs у папці Міграції
2. У SSMS видаліть системну таблицю __MigrationHistory.

Створення початкової міграції:

1. У консолі диспетчера пакунків:

   Enable-Migrations -EnableAutomaticMigrations -ContextTypeName
   NamespaceOfContext.ContextA -ProjectName ProjectContextIsInIfNotMainOne
   -StartupProjectName NameOfMainProject  -ConnectionStringName ContextA

2. У Провіднику рішень: Перейменуйте Migrations.Configuration.cs на Migrations.ConfigurationA.cs. Це має автоматично перейменувати конструктор, якщо використовується Visual Studio. Переконайтесь, що це так. Редагування ConfigurationA.cs: Змініть простір імен на NamespaceOfContext.Migrations.MigrationsA

3. Enable-Migrations -EnableAutomaticMigrations -ContextTypeName
   NamespaceOfContext.ContextB -ProjectName ProjectContextIsInIfNotMainOne
   -StartupProjectName NameOfMainProject  -ConnectionStringName ContextB

4. У Провіднику рішень: Перейменуйте Migrations.Configuration.cs на Migrations.ConfigurationB.cs. Знову ж таки, переконайтеся, що конструктор також був перейменований відповідним чином. Редагування ConfigurationB.cs: Змініть простір імен на NamespaceOfContext.Migrations.MigrationsB

5. add-migration InitialBSchema -IgnoreChanges -ConfigurationTypeName
   ConfigurationB -ProjectName ProjectContextIsInIfNotMainOne
   -StartupProjectName NameOfMainProject  -ConnectionStringName ContextB 

6. Update-Database -ConfigurationTypeName ConfigurationB -ProjectName
   ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject
   -ConnectionStringName ContextB

7. add-migration InitialSurveySchema -IgnoreChanges -ConfigurationTypeName
   ConfigurationA -ProjectName ProjectContextIsInIfNotMainOne -StartupProjectName
   NameOfMainProject  -ConnectionStringName ContextA 

8. Update-Database -ConfigurationTypeName ConfigurationA -ProjectName
   ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject
   -ConnectionStringName ContextA

Кроки для створення сценаріїв міграції в консолі диспетчера пакунків:

1. Виконати команду

   Add-Migration MYMIGRATION -ConfigurationTypeName ConfigurationA -ProjectName
   ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject
   -ConnectionStringName ContextA

   або -

   Add-Migration MYMIGRATION -ConfigurationTypeName ConfigurationB -ProjectName
   ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject
   -ConnectionStringName ContextB

   Добре повторити цю команду, поки зміни не будуть застосовані до БД.

2. Або запустіть скрипти на потрібній локальній базі даних або запустіть Update-Database без -Script, щоб застосувати локально:

   Update-Database -ConfigurationTypeName ConfigurationA -ProjectName
   ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject
   -ConnectionStringName ContextA

   або -

   Update-Database -ConfigurationTypeName ConfigurationB -ProjectName
   ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject
   -ConnectionStringName ContextB

Я просто наткнувся на ту ж проблему, і я застосував таке рішення (все з консолі менеджера пакунків)

PM> Enable-Migrations -MigrationsDirectory "Migrations\ContextA" -ContextTypeName MyProject.Models.ContextA
PM> Enable-Migrations -MigrationsDirectory "Migrations\ContextB" -ContextTypeName MyProject.Models.ContextB

Це створить дві окремі папки в папці Міграції. Кожен буде містити створений Configuration.csфайл. На жаль, вам все одно доведеться перейменувати ці Configuration.csфайли, інакше з’являться скарги на наявність двох з них. Я перейменував свої файли в ConfigA.csтаConfigB.cs

EDIT : (люб’язно Кевін МакПіат) Пам'ятайте, перейменуючи файли Configuration.cs, також перейменуйте назви класів та конструктори / EDIT

З цією структурою можна просто обійтися

PM> Add-Migration -ConfigurationTypeName ConfigA
PM> Add-Migration -ConfigurationTypeName ConfigB

Який створить файли коду для міграції всередині папки поруч із конфігураційними файлами (це приємно зберігати ці файли разом)

PM> Update-Database -ConfigurationTypeName ConfigA
PM> Update-Database -ConfigurationTypeName ConfigB

І останнє, але не менш важливо, ці дві команди застосовують правильні міграції до своїх баз даних, що відповідають вимогам.

EDIT 08 лютого 2016: Я трохи провів тестування з версією 7.0.0-rc1-16348 EF7

Я не зміг отримати можливість -o | --outputDir працювати. Це продовжувало даватиMicrosoft.Dnx.Runtime.Common.Commandline.CommandParsingException: Unrecognized command or argument

Однак це схоже на те, що перший раз, коли миграція додається, вона додається в папку Міграції, а наступна міграція для іншого контексту автоматично поміщається в підрозділ міграцій.

Оригінальні назви, ContextAздається, порушують деякі умови іменування, тому я зараз використовую ContextAContextі ContextBContext. Використовуючи ці імена, ви можете використовувати такі команди: (зауважте, що мій dnx все ще працює з консолі диспетчера пакунків, і я не люблю відкривати окреме вікно CMD для міграцій)

PM> dnx ef migrations add Initial -c "ContextAContext"
PM> dnx ef migrations add Initial -c "ContextBContext"

Це створить знімок моделі та початкову міграцію в Migrationsпапці для ContextAContext. Він створить папку з іменем, ContextBщо містить ці файли дляContextBContext

Я вручну додав ContextAпапку і перемістив файли міграції з ContextAContextцієї папки. Потім я перейменував простір імен всередині цих файлів (файл знімка, початкова міграція і зауважу, що під початковим файлом міграції є третій файл ... дизайнер.cs). Мені довелося додати .ContextAдо простору імен, і звідси фреймворк знову обробляє його.

Використання наступних команд створило б нову міграцію для кожного контексту

PM>  dnx ef migrations add Update1 -c "ContextAContext"
PM>  dnx ef migrations add Update1 -c "ContextBContext"

і створені файли поміщаються у правильні папки.

Якщо у вас вже є "Конфігурація" з багатьма міграціями, і ви хочете зберегти це так, як є, ви завжди можете створити новий клас "Конфігурація", дайте йому іншу назву, наприклад

class MyNewContextConfiguration : DbMigrationsConfiguration<MyNewDbContext>
{
   ...
}

тоді просто видайте команду

Add-Migration -ConfigurationTypeName MyNewContextConfiguration InitialMigrationName

і EF допоможе без проблем перемістити міграцію. Нарешті оновіть вашу базу даних, відтепер EF буде скаржитися, якщо ви не скажете йому, яку конфігурацію ви хочете оновити:

Update-Database -ConfigurationTypeName MyNewContextConfiguration 

Зроблено.

Вам не потрібно мати справу з Enable-Migrations, оскільки він скаржиться на те, що "Конфігурація" вже існує, а перейменування існуючого класу Configuration призведе до проблем міграції.

Ви можете орієнтуватися на різні бази даних або одну і ту ж, всі конфігурації будуть добре розподіляти таблицю __MigrationHistory.

Якщо існує більше баз даних, використовуйте наступні коди в PowerShell

Add-Migration Starter -context EnrollmentAppContext 

• "Стартер" - це назва міграції

• "EnrollmentAppContext" - це ім'я мого додатка Контекст

Ви можете відкрити PowerShell в VS, виконавши: Tools->NuGet Package Manager->Package Manager Console

Для оновлення типу бази даних наступні коди в PowerShell ...

Update-Database -context EnrollmentAppContext

* якщо існує більше ніж одна база даних, використовуйте лише ці коди, інакше не потрібно.

EF 4.7 насправді дає підказку під час запуску міграції Enable у різних контекстах.

У збірці "Service.Domain" було знайдено більше одного типу контексту.

To enable migrations for 'Service.Domain.DatabaseContext.Context1', 
use Enable-Migrations -ContextTypeName Service.Domain.DatabaseContext.Context1.
To enable migrations for 'Service.Domain.DatabaseContext.Context2',
use Enable-Migrations -ContextTypeName Service.Domain.DatabaseContext.Context2.