Migration.exe -connectionString arguments ne fonctionne pas faire la migration EF sur le serveur CI

Question

J'essaye de faire la mise à jour de la base de données de la première migration de code sur un serveur de construction.

J'ai lu à propos de l'utilisation de migration.exe à partir des outils EF 6, et en passant misc. paramètres de contexte et de connexion en tant qu'arguments de l'appel de migration.exe.

Je veux être en mesure de spécifier la chaîne de connexion, le catalogue par défaut et la sécurité directement comme arguments. Le problème est que lorsque j'ai spécifié ma connectiontring etc. comme: migrate.exe Ef.Data.DLL/ConnectionString: "Source de données = myserver; Initial Catalog = MonCatalogue; Sécurité intégrée = true"/connectionProviderName: Système .Data.SqlClient/bavard

Alors Migrate.exe jetteront et erreur: System.InvalidOperationException: Aucune chaîne de connexion nommée « MyContext » n'a pu être trouvée dans le fichier de configuration d'application

Mon contexte est défini dans le code comme: public MyContext() : base ("name = MyContext")

Il s'attend donc à ce que la chaîne de connexion "MyContext" essaie toujours d'utiliser App.config og web.config pour cela, mais cela ne devrait pas être le cas, parce que je transmets cette information en arguments.

Si j'essaie de spécifier un ConnectionStringName comme argument (-connectionStringName: MyContext) le long des autres arguments. le j'obtiens: ERREUR: Un seul de/connectionStringName ou/connectionString peut être spécifié.

Donc, je suis bloqué ici. Cant semble avoir résolu celui-ci. Toutes les idées sont très appréciées.

Answer 1

J'ai eu le même problème aujourd'hui. Pour moi, il a été triée en changeant mon constructeur de contexte, de:

public RootContext() : base("name=MyContext") 

à ceci:

public RootContext() : this("MyContext") 

Avoir la name= devant le nom du contexte forces la valeur à trouver dans la config sinon il jette une erreur. C'est très pratique lorsque vous ne faites que déployer à partir de Visual Studio, car il est utile de lancer des erreurs si vos chaînes ne correspondent pas, mais pas si vous essayez d'automatiser les migrations dans différents environnements à partir de la ligne de commande. Donc, si vous effectuez cette modification, soyez prudent lorsque vous exécutez vos migrations dans VS - si vos chaînes ne correspondent pas, elles continueront heureusement et créeront une nouvelle base de données dans LocalDB nommée "MyContext" sans vous dire que c'est ce qu'elle fait!