Attendez ! Quel fichier de configuration ? (Entity Framework Connection String)

Question

J'ai donc créé mon modèle d'entité dans une bibliothèque de classes distincte. J'ai dû ajouter la chaîne de connexion à la app.config de cette bibliothèque de classes. Puis j'ai ajouté une référence pour ce projet dans mon application web. J'ai ajouté la même chaîne de connexion dans le fichier web.config de mon application web en pensant que c'est de là qu'Entity Framework lira la chaîne de connexion.

Tout allait bien jusqu'à ce que je déploie mon application web. Lorsque j'ai déployé, j'ai modifié la chaîne de connexion dans le champ web.config (pas app.config de la bibliothèque de classes) et j'ai commencé à avoir des erreurs. Après avoir fait quelques recherches, j'ai découvert que la chaîne de connexion dans les deux applications web.config y app.config doit correspondre !

C'est juste stupide ! Chaque fois que j'ai besoin de déployer mon application web dans un environnement différent, je dois revenir en arrière et modifier la chaîne de connexion dans le fichier de configuration de l'application. app.config et ensuite recompiler mon projet de bibliothèque de classe juste pour qu'il puisse obtenir la chaîne de connexion rafraîchie ?

Quelqu'un a-t-il trouvé une meilleure façon de procéder ? Je veux dire, je ne peux pas être la seule personne à avoir pensé à mettre le modèle d'entité dans une assemblée séparée.

Solution possible (si vous utilisez EF 4.1) : Puisque la seule raison pour laquelle nous avons besoin d'avoir app.config dans un projet de bibliothèque de classes est pour le concepteur EF. Si nous abandonnons l'approche du concepteur et passons au Code-First (EF 4.1), vous n'aurez pas besoin d'avoir un fichier app.config pour votre projet de bibliothèque de classes.

Answer 1

Nous nous sommes retrouvés dans la même situation. J'ai demandé à chaque développeur de ne compiler l'assemblage EF qu'avec la première chaîne de connexion sélectionnée.

Ainsi, lors du déploiement, une seule chaîne de connexion est nécessaire dans le web.config.

Finalement, si chaque machine de développement et chaque serveur de déploiement dispose des informations de connexion correctes (pour cette machine) dans la première (et, espérons-le, la seule) chaîne de connexion (c'est-à-dire pas ConnectionString4), la vie est facile.

En gros, des chaînes de connexion supplémentaires sont ajoutées par le concepteur à la chaîne de connexion du développeur lorsque la chaîne de connexion par défaut (la dernière sélectionnée) ne peut pas se connecter.

De plus, il n'y a aucune raison de se sentir mal de placer la couche de données dans une assemblée séparée. C'est parfois préférable.

Enfin, il est important de s'assurer que le fichier de configuration qui contient la chaîne de connexion n'est pas relié au contrôle de la source -- la chaîne de connexion est souvent localisée et causera le "multi-connection-string-issue" dans EF et LINQ to SQL s'il continue à être écrasé avec de mauvaises valeurs chaque fois que vous mettez à jour votre projet à partir du contrôle de la source.