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

Question

J'ai récemment commencé à utiliser Entity Framework migrations et a remarqué que le nom de base de données n'est pas en tirant à travers, pour moi, quand je lance l' Update-Database commande.

Mon connectionstring est:

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

La première fois que je lance la mise à Jour de la Base de données de ma base de données est créée avec le nom TestDB. Cependant, dès que je fais un changement à l'une de mes entités, il ne sera pas de mise à jour de plus pour moi, si j'ajoute un Projet de Démarrage de Nom (je suis en utilisant un multi solution de projet):

Update-Database -StartUpProjectName "TestDB.Data"

Ceci permet alors une autre nouvelle base de données dont les migrations sont toujours continuer à l'utiliser. Je ne me dérange pas d'avoir à le mettre dans la StartUpProjectName commande mais est-il un moyen de remplacer le nom par défaut de la base de données de ce produit? Il crée toujours la base de données

TestDB.Data.DataContext

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

Comme une note, je pense que la raison j'ai besoin de spécifier le StartUpProjectName est que j'ai une multicouche de configuration de projet. Les Migrations fichier de Configuration est dans mes "Données" du projet, les entités ou les modèles sont dans mon "Domaine" du projet, etc. Je fais aussi pas d'initialiser les options dans mon Global.asax.cs fichier que je l'aurais utilisé précédemment sur le premier code ef 4.2. Donc, dans mon projet j'ai juste un DataContext dans mon projet de Données et les Migrations de Configuration dans ce projet également.

EDIT:

Depuis que j'ai à l'origine de l'installation à cette question, je suis tombé sur la "bonne" façon de nommer une base de données dans une solution multiprojet. Si la réponse ci-dessous, vous sont dupliquer votre site web.config dans un autre domaine qui n'est pas une solution idéale. Au lieu de cela, vous pouvez simplement mettre le nom de votre DbContext en faisant quelque chose comme ceci (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,

Riche

Answer 1

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.

Answer 2

Lorsque vous effectuez update-database vous devez spécifier le projet qui contient les migrations. Assurez-vous que vous avez un app.config le fichier dans ce projet qui contient la chaîne de connexion approprié.

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

Quand j'ai fait une semblable installation j'ai dû ajouter de la chaîne de connexion dans les deux endroits. Un peu maladroit, mais il fonctionne.

Answer 3

Vous pouvez avoir votre chaîne de connexion stockées dans le site web.config dans votre projet de site web et de la DBContext et la migration des fichiers dans un autre projet et partagent toujours la même chaîne de connexion. Cependant, vous devez vous assurer que ainsi que de mettre les Données du projet (ou quel que soit le projet a l'DBContext etc. dans celui-ci) comme le projet par défaut pour le Gestionnaire de paquets de la Console, vous devez ÉGALEMENT vous assurer que votre site web est mis à la valeur par Défaut de Démarrage du Projet!!!

Je ne vois pas ce document n'importe où, mais une frénétique 24 heures de ne pas être en mesure de comprendre pourquoi mon migrations où soudain appliquée à un SQLExpress db, m'a conduit à cette conclusion.

Answer 4

J'ai essayé avec la Dernière EF5 de Nuget.

Toutefois Update-Database ne lisent pas l' App.config du projet, qui contiennent les migrations (tout comme la réponse il y a 1 an) mais il ne lira *.config depuis le démarrage du projet. Il est génial mais j'découvrir comment Add-Migration et Update-Database trouver une chaîne de connexion ici:

1. Il essaie d'obtenir "DefaultConnection" chaîne de connexion de la première
2. Puis il tente d'obtenir de la chaîne de connexion nom basé sur le contexte de la nom de la classe. E. g. J'ai MyContext classe dérivée de l' DbContext si je peux utiliser le "MyContext" chaîne de connexion nom. Utile lorsque j'ai plusieurs db connections.
3. Si le lien ci-dessus nom de la chaîne n'est pas trouvée, il a échoué et ne montrent pas de "DefaultConnection" chaîne de connexion, à moins que vous ravitailler les -ConnectionStringName paramètre. Voir get-help Update-Database pour afficher la page d'aide dans le Gestionnaire de paquets de la Console.

Il n'y a pas de réessayer ou de secours tentative, donc si le "DefaultConnection" contiennent de mal chaîne de connexion, il sera tout simplement montrer l'erreur.

Si les deux DefaultConnection et le contexte nom existent dans les chaînes de connexion, DefaultConnection aura préséance.

Je préfère #2 devient le premier essai parce que le nom est plus spécifique, mais les étapes ci-dessus est ce que EF5 Migrations faire lors de la tentative de connexion à la db.