¿Cómo habilito las migraciones de EF para contextos múltiples para separar bases de datos?

¿Cómo habilito las migraciones de Entity Framework 5 (versión 5.0.0) para múltiples contextos DB en el mismo proyecto, donde cada contexto corresponde a su propia base de datos? Cuando ejecuto Enable-Migrations en la consola de PM (Visual Studio 2012), hay un error debido a que hay múltiples contextos:

 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. 

Si ejecuto Enable-Migrations -ContextTypeName DatabaseService.Models.Product1DbContext no puedo ejecutar Enable-Migrations -ContextTypeName DatabaseService.Models.Product2DbContext porque ya existe una migración: las Migrations have already been enabled in project 'DatabaseService'. To overwrite the existing migrations configuration, use the -Force parameter. Migrations have already been enabled in project 'DatabaseService'. To overwrite the existing migrations configuration, use the -Force parameter.

La segunda llamada a Enable-Migrations está fallando porque el archivo Configuration.cs ya existe. Si cambia el nombre de esa clase y archivo, debe poder ejecutar ese 2º Enable-Migrations, que creará otro Configuration.cs.

Luego deberá especificar qué configuración desea usar al actualizar las bases de datos.

 Update-Database -ConfigurationTypeName MyRenamedConfiguration 

Además de lo que @ckal sugirió, es fundamental dar a cada uno de los Design.cs su propio espacio de nombres. Si no lo hace, EF intentará aplicar las migraciones al contexto incorrecto.

Aquí están los pasos específicos que funcionan bien para mí.

Si las migraciones están desordenadas y quieres crear una nueva “línea base”:

  1. Elimine cualquier archivo .cs existente en la carpeta Migraciones
  2. En SSMS, elimine la tabla del sistema __MigrationHistory.

Creando la migración inicial:

  1. En la consola del Administrador de paquetes:

     Enable-Migrations -EnableAutomaticMigrations -ContextTypeName NamespaceOfContext.ContextA -ProjectName ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject -ConnectionStringName ContextA 
  2. En el Explorador de soluciones: cambie el nombre Migrations.Configuration.cs a Migrations.ConfigurationA.cs. Esto debería cambiar automáticamente el nombre del constructor si se usa Visual Studio. Asegúrate de que lo haga. Editar ConfigurationA.cs: Cambie el espacio de nombre a NamespaceOfContext.Migrations.MigrationsA

  3.  Enable-Migrations -EnableAutomaticMigrations -ContextTypeName NamespaceOfContext.ContextB -ProjectName ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject -ConnectionStringName ContextB 
  4. En el Explorador de soluciones: cambie el nombre Migrations.Configuration.cs a Migrations.ConfigurationB.cs. De nuevo, asegúrese de que el constructor también se renombre apropiadamente. Edite ConfigurationB.cs: cambie el espacio de nombre a 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 

Pasos para crear scripts de migración en la consola de Package Manager:

  1. Ejecutar comando

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

    o –

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

    Está bien volver a ejecutar este comando hasta que se apliquen cambios a la base de datos.

  2. Ejecute los scripts contra la base de datos local deseada o ejecute Update-Database sin -Script para aplicar localmente:

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

    o –

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

Acabo de tropezar con el mismo problema y utilicé la siguiente solución (todo desde la consola del Administrador de paquetes)

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

Esto creará 2 carpetas separadas en la carpeta Migraciones. Cada uno contendrá el archivo Configuration.cs generado. Desafortunadamente, todavía tiene que cambiar el nombre de esos archivos Configuration.cs , de lo contrario, habrá quejas acerca de tener dos de ellos. ConfigA.cs nombre de mis archivos a ConfigA.cs y ConfigB.cs

EDITAR : (cortesía de Kevin McPheat) Recuerde al cambiar el nombre de los archivos Configuration.cs, también cambie el nombre de los nombres de las clases y los constructores / EDIT

Con esta estructura puedes simplemente hacer

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

Que creará los archivos de código para la migración dentro de la carpeta al lado de los archivos de configuración (esto es bueno para mantener esos archivos juntos)

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

Y por último, pero no menos importante, esos dos comandos aplicarán las migraciones correctas a sus bases de datos correspondientes.

EDITAR 08 de febrero de 2016: He hecho algunas pruebas con EF7 versión 7.0.0-rc1-16348

No pude hacer funcionar la opción -o | –outputDir. Siguió dando Microsoft.Dnx.Runtime.Common.Commandline.CommandParsingException: Unrecognized command or argument

Sin embargo, parece que la primera vez que se agrega una migración, se agrega a la carpeta Migraciones, y una migración posterior para otro contexto se coloca automáticamente en una subdolder de migraciones.

Los nombres originales ContextA parecen violar algunas convenciones de nombres, por lo que ahora uso ContextAContext y ContextBContext . Usando estos nombres, podría usar los siguientes comandos: (tenga en cuenta que mi dnx todavía funciona desde la consola del administrador de paquetes y no me gusta abrir una ventana CMD separada para hacer migraciones)

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

Esto creará una instantánea modelo y una migración inicial en la carpeta Migrations para ContextAContext . ContextB una carpeta llamada ContextB contiene estos archivos para ContextBContext

ContextA manualmente una carpeta ContextA y moví los archivos de migración de ContextAContext a esa carpeta. Luego cambié el nombre del espacio de nombres dentro de esos archivos (archivo de instantáneas, migración inicial y tenga en cuenta que hay un tercer archivo debajo del archivo de migración inicial … designer.cs). Tuve que agregar .ContextA al espacio de nombres, y desde allí el marco lo maneja automáticamente de nuevo.

El uso de los siguientes comandos crearía una nueva migración para cada contexto

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

y los archivos generados se colocan en las carpetas correctas.

En caso de que ya tenga una “Configuración” con muchas migraciones y quiera mantener esto como está, siempre puede crear una nueva clase de “Configuración”, darle otro nombre, como

 class MyNewContextConfiguration : DbMigrationsConfiguration { ... } 

entonces solo emita el comando

 Add-Migration -ConfigurationTypeName MyNewContextConfiguration InitialMigrationName 

y EF andamiará la migración sin problemas. Finalmente actualice su base de datos, de ahora en adelante, EF se quejará si no le dice qué configuración desea actualizar:

 Update-Database -ConfigurationTypeName MyNewContextConfiguration 

Hecho.

No es necesario tratar con Enable-Migrations, ya que se quejará de que “Configuración” ya existe, y el cambio de nombre de su clase de Configuración existente traerá problemas al historial de migración.

Puede orientar diferentes bases de datos, o la misma, todas las configuraciones compartirán muy bien la tabla __MigrationHistory.