web-dev-qa-db-fra.com

Comment nommer explicitement la base de données lors de l'utilisation d'Entity Framework Migrations 4.3

J'ai récemment commencé à utiliser les migrations Entity Framework et j'ai remarqué que le nom de la base de données ne me parvient pas lorsque j'exécute le Update-Database commande.

Ma chaîne de connexion est:

<connectionStrings>
<add name="DataContext" connectionString="Server=.\SQLEXPRESS;Initial Catalog=TestDB;Trusted_Connection=Yes;" providerName="System.Data.SqlClient" />
</connectionStrings>

La toute première fois que je lance Update-Database ma base de données est créée avec le nom correct TestDB . Cependant, dès que j'apporterai une modification à l'une de mes entités, elle ne se mettra plus à jour à moins que j'ajoute un nom de projet de démarrage (j'utilise une solution multi-projets):

Update-Database -StartUpProjectName "TestDB.Data"

Cela crée alors une autre nouvelle base de données que les migrations continueront toujours d'utiliser. Cela ne me dérange pas d'avoir à mettre la commande StartUpProjectName mais existe-t-il un moyen de remplacer le nom par défaut de la base de données que cela produit? Il crée toujours la base de données comme

TestDB.Data.DataContext

Existe-t-il un moyen de s'assurer que la base de données créée lors du passage du nom StartUpProject est juste appelée TestDB ou est-ce une limitation de l'utilisation du paramètre StartUpProjectName?

En tant que note, je pense que la raison pour laquelle je dois spécifier le StartUpProjectName est que j'ai une configuration de projet multicouche. Le fichier de configuration des migrations se trouve dans mon projet "Données", les entités/modèles se trouvent dans mon projet "Domaine", etc. Je n'ai actuellement aucune option d'initialisation dans mon fichier Global.asax.cs comme je l'aurais utilisé précédemment sur code premier ef 4.2. Donc, dans mon projet, j'ai juste un DataContext dans mon projet de données et la configuration des migrations dans ce projet également.

MODIFIER:

Depuis que j'ai configuré cette question à l'origine, je suis tombé sur la manière "correcte" de nommer une base de données dans une solution multiprojet. Bien que la réponse ci-dessous fonctionne, cela signifie que vous dupliquez votre web.config dans un autre domaine, ce qui n'est pas une solution idéale. Au lieu de cela, vous pouvez simplement mettre le nom dans votre DbContext en faisant quelque chose comme ça (DataContext est juste le nom que j'ai utilisé dans mon projet):

public class DataContext : DbContext
{
    public DataContext() : base("DatabaseNameHere")
    { }

    public DbSet<Table1> Table1 { get; set; }
    public DbSet<Table2> Table2 { get; set; }

    public virtual void Commit()
    {
        base.SaveChanges();
    }
}

Merci,

Riches

entity-frameworkef-migrations
56
Richard Reddy

En faisant update-database vous devez spécifier le projet qui contient les migrations. Assurez-vous que vous disposez d'un app.config fichier dans ce projet qui contient la chaîne de connexion correcte.

Lors du fractionnement d'une application sur plusieurs projets, la chaîne de connexion utilisée lors de l'exécution de l'application est celle du projet démarré. Lors de la migration, la chaîne de connexion utilisée est celle du projet contenant les migrations.

Lorsque j'ai fait une configuration similaire, j'ai dû ajouter la chaîne de connexion à deux endroits. Un peu maladroit, mais ça marche.

33
Anders Abel

Vous pouvez éviter de le gérer dans app.config en le proposant comme paramètre:

Update-Database -Verbose 
 -ConnectionString "CONNECTIONSTRING" 
 -ConnectionProviderName "System.Data.SqlClient"
 -StartupProjectName WEBSITE_PROJECT -ProjectName MIGRATION_PROJECT

Easy-piezy, si vous aimez taper à l'infini.

76
Scott Stafford

Vous pouvez avoir votre chaîne de connexion stockée dans le web.config de votre projet de site Web et les fichiers DBContext et de migration dans un autre projet et toujours partager la même chaîne de connexion. Cependant, vous devez vous assurer qu'en plus de définir le projet Data (ou tout autre projet contenant le DBContext, etc.) comme projet par défaut pour la console du gestionnaire de packages, vous vous devez également vous assurer que votre site Web est défini sur le projet de démarrage par défaut !!!

Je ne peux voir cela documenté nulle part, mais 24 heures frénétiques de ne pas pouvoir comprendre pourquoi mes migrations ont soudainement été appliquées à une base de données SQLExpress, m'ont amené à cette conclusion.

23
Mike Dymond

J'ai essayé avec Latest EF5 de Nuget.

Toutefois Update-Database ne lit pas le App.config du projet qui contient les migrations (tout comme la réponse d'il y a 1 an) mais il ne lira que *.config de démarrage du projet. C'est super mais je découvre comment Add-Migration et Update-Database trouvez ici une chaîne de connexion appropriée:

  1. Il essaie d'obtenir la chaîne de connexion "DefaultConnection" en premier
  2. Ensuite, il essaie d'obtenir le nom de la chaîne de connexion en fonction du nom de la classe de contexte. Par exemple. J'ai la classe MyContext dérivée de DbContext donc je peux utiliser le nom de chaîne de connexion "MyContext". Utile lorsque j'ai plusieurs connexions db.
  3. Si les deux noms de chaîne de connexion ci-dessus ne sont pas trouvés, il échouera et n'affichera aucune chaîne de connexion "DefaultConnection" à moins que vous ne fournissiez le -ConnectionStringName paramètre. Voir get-help Update-Database pour afficher la page d'aide dans la console du gestionnaire de packages.

Il n'y a pas de nouvelle tentative ou tentative de secours, donc si "DefaultConnection" contient une chaîne de connexion incorrecte, il affichera simplement une erreur.

Si DefaultConnection et le nom de contexte existent dans les chaînes de connexion, DefaultConnection aura la priorité.

Je préférerais que # 2 devienne le premier essai parce que le nom est plus spécifique mais les étapes ci-dessus sont ce que font les migrations EF5 lors de la tentative de connexion à la base de données.

9
CallMeLaNN