Comment activer les migrations EF pour plusieurs contextes afin de séparer les bases de données?

Comment activer les migrations Entity Framework 5 (version 5.0.0) pour plusieurs contextes de firebase database dans un même projet, chaque contexte correspondant à sa propre firebase database? Lorsque j’exécute Enable-Migrations dans la console PM (Visual Studio 2012), il existe une erreur en raison de l’existence de plusieurs contextes:

 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 je lance Enable-Migrations -ContextTypeName DatabaseService.Models.Product1DbContext Je ne suis pas autorisé à exécuter Enable-Migrations -ContextTypeName DatabaseService.Models.Product2DbContext car une migration existe déjà: les 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.

    Le 2ème appel à Enable-Migrations échoue car le fichier Configuration.cs existe déjà. Si vous renommez cette classe et ce fichier, vous devriez pouvoir exécuter ce 2nd Enable-Migrations, qui créera un autre Configuration.cs.

    Vous devrez ensuite spécifier la configuration que vous souhaitez utiliser lors de la mise à jour des bases de données.

     Update-Database -ConfigurationTypeName MyRenamedConfiguration 

    En plus de ce que @ckal a suggéré, il est essentiel de donner à chaque configuration renommée son propre espace de noms. Si vous ne le faites pas, EF tentera d’appliquer les migrations au mauvais contexte.

    Voici les étapes spécifiques qui fonctionnent bien pour moi.

    Si les migrations sont perturbées et que vous souhaitez créer une nouvelle “ligne de base”:

    1. Supprimer tous les fichiers .cs existants dans le dossier Migrations
    2. Dans SSMS, supprimez la table système __MigrationHistory.

    Création de la migration initiale:

    1. Dans la console du gestionnaire de packages:

       Enable-Migrations -EnableAutomaticMigrations -ContextTypeName NamespaceOfContext.ContextA -ProjectName ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject -ConnectionSsortingngName ContextA 
    2. Dans l’Explorateur de solutions: renommez Migrations.Configuration.cs à Migrations.ConfigurationA.cs. Cela devrait automatiquement renommer le constructeur si vous utilisez Visual Studio. Assurez-vous que c’est le cas. Modifier ConfigurationA.cs: changez l’espace de noms en NamespaceOfContext.Migrations.MigrationsA

    3.  Enable-Migrations -EnableAutomaticMigrations -ContextTypeName NamespaceOfContext.ContextB -ProjectName ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject -ConnectionSsortingngName ContextB 
    4. Dans l’Explorateur de solutions: renommez Migrations.Configuration.cs en Migrations.ConfigurationB.cs. Encore une fois, assurez-vous que le constructeur est également renommé de manière appropriée. Modifier ConfigurationB.cs: changez l’espace de noms en NamespaceOfContext.Migrations.MigrationsB

    5.  add-migration InitialBSchema -IgnoreChanges -ConfigurationTypeName ConfigurationB -ProjectName ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject -ConnectionSsortingngName ContextB 
    6.  Update-Database -ConfigurationTypeName ConfigurationB -ProjectName ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject -ConnectionSsortingngName ContextB 
    7.  add-migration InitialSurveySchema -IgnoreChanges -ConfigurationTypeName ConfigurationA -ProjectName ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject -ConnectionSsortingngName ContextA 
    8.  Update-Database -ConfigurationTypeName ConfigurationA -ProjectName ProjectContextIsInIfNotMainOne -StartupProjectName NameOfMainProject -ConnectionSsortingngName ContextA 

    Étapes pour créer des scripts de migration dans la console du gestionnaire de packages:

    1. Exécuter la commande

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

      ou –

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

      Il est correct de réexécuter cette commande jusqu’à ce que des modifications soient appliquées à la firebase database.

    2. Exécutez les scripts sur la firebase database locale souhaitée ou exécutez Update-Database sans -Script pour appliquer localement:

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

      ou –

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

    Je viens de tomber sur le même problème et j’ai utilisé la solution suivante (tout de la console du gestionnaire de paquets)

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

    Cela créera 2 dossiers distincts dans le dossier Migrations. Chacun contiendra le fichier Configuration.cs généré. Malheureusement, vous devez toujours renommer ces fichiers Configuration.cs , sinon vous en aurez deux. J’ai renommé mes fichiers en ConfigA.cs et ConfigB.cs

    EDIT : (avec la permission de Kevin McPheat) Rappelez-vous lors du renommage des fichiers Configuration.cs, renommez également les noms de classe et les constructeurs / EDIT

    Avec cette structure, vous pouvez simplement faire

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

    Qui va créer les fichiers de code pour la migration dans le dossier à côté des fichiers de configuration (c’est bien de garder ces fichiers ensemble)

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

    Enfin, ces deux commandes appliqueront les migrations correctes à leurs bases de données correspondantes.

    EDIT 08 févr. 2016: J’ai fait un petit test avec EF7 version 7.0.0-rc1-16348

    Je n’ai pas pu obtenir l’option -o | –outputDir pour fonctionner. Il a continué à donner Microsoft.Dnx.Runtime.Common.Commandline.CommandParsingException: Unrecognized command or argument

    Cependant, il semble que la première fois qu’une migration soit ajoutée, elle soit ajoutée dans le dossier Migrations et qu’une migration ultérieure pour un autre contexte soit automatiquement placée dans un sous-dossier de migrations.

    Les noms d’origine ContextA semble violer certaines conventions de dénomination. J’utilise maintenant ContextAContext et ContextBContext . En utilisant ces noms, vous pouvez utiliser les commandes suivantes: (notez que mon dnx fonctionne toujours à partir de la console du gestionnaire de paquets et je n’aime pas ouvrir une fenêtre CMD séparée pour effectuer des migrations)

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

    Cela créera un instantané du modèle et une migration initiale dans le dossier Migrations pour ContextAContext . Il va créer un dossier nommé ContextB contenant ces fichiers pour ContextBContext

    J’ai ajouté manuellement un dossier ContextA et déplacé les fichiers de migration de ContextAContext dans ce dossier. Ensuite, j’ai renommé l’espace de noms dans ces fichiers (fichier d’instantané, migration initiale et notez qu’il existe un troisième fichier sous le fichier de migration initial … designer.cs). J’ai dû append .ContextA à l’espace de noms et, à partir de là, le framework le gère à nouveau automatiquement.

    L’utilisation des commandes suivantes créerait une nouvelle migration pour chaque contexte

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

    et les fichiers générés sont placés dans les bons dossiers.

    Si vous avez déjà une “Configuration” avec de nombreuses migrations et que vous souhaitez conserver le même état, vous pouvez toujours créer une nouvelle classe “Configuration”, lui donner un autre nom, comme

     class MyNewContextConfiguration : DbMigrationsConfiguration { ... } 

    puis lancez simplement la commande

     Add-Migration -ConfigurationTypeName MyNewContextConfiguration InitialMigrationName 

    et EF échafaudera la migration sans problème. Enfin, mettez à jour votre firebase database, à partir de maintenant, EF se plaindra si vous ne lui dites pas quelle configuration vous souhaitez mettre à jour:

     Update-Database -ConfigurationTypeName MyNewContextConfiguration 

    Terminé.

    Vous n’avez pas besoin de traiter Enable-Migrations car il se plaint que “Configuration” existe déjà, et renommer votre classe de configuration existante entraînera des problèmes dans l’historique de la migration.

    Vous pouvez cibler différentes bases de données, ou la même, toutes les configurations partageront bien la table __MigrationHistory.