2010-08-08 3 views
3

J'ai un système comprenant 5 applications. Chaque application accède à une base de données via une bibliothèque DAL. Dans le DAL j'ai un app.config avec l'entrée suivante:en utilisant une base de données SQL dans plusieurs projets

<connectionStrings> 
<add name="DataAccessLayer.Properties.Settings.ConnectionString" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=c:\users\something\something\MyDB.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True" providerName="System.Data.SqlClient" /> 
</connectionStrings> 

Utilisation du chemin complet du attachDbFilename fonctionne très bien. Mais je ne suis pas content:

  1. J'ai copié le fichier app.config dans chaque application qui utilise la base de données. Le meilleur moyen de le faire - copier le DAL app.config en tant que lien dans les autres projets?

  2. Je ne veux pas un chemin complet, quand il s'agit de déploiement qui ne va pas travailler. Les chemins relatifs dans app.config ne semblent pas fonctionner. Idéalement, je voudrais être en mesure de tirer le DAL du contrôle de la source sur n'importe quel ordinateur et ne pas avoir à se soucier de changer la chaîne de connexion à chaque fois. Ceci: http://blogs.msdn.com/b/smartclientdata/archive/2005/08/26/456886.aspx parle de | DataDirectory | à des fins de déploiement mais cela ne fonctionne pas pour moi dans le débogage (sauf si je l'utilise mal, voir 3)

  3. Cela pourrait être mieux comme une question distincte, mais il est lié à 2. - Y at-il un " bonne "façon d'organiser plusieurs projets pour le débogage? J'ai créé un répertoire bin et dans chaque paramètres du projet, je copie le dll/exe dans ce répertoire bin. J'ai également une copie de la base de données ici (je n'ai essayé aucun chemin dans le fichier app.config mais cela n'a pas fonctionné non plus, ni | DataDirectory |). Aussi incroyablement ennuyeux est que les chemins relatifs ne fonctionnent pas dans le paramètre Debug \ Working Directory non plus, il semble donc que c'est un endroit qui devrait changer à chaque fois que le code est extrait sur une nouvelle machine?

Excuses pour la guerre et la paix et merci d'avance pour vos idées.

Répondre

4

Deux réponses - mais pas vraiment des solutions complètes:

1) J'ai copié le fichier app.config dans chaque application qui utilise la base de données. Le meilleur moyen de le faire - copier le DAL app.config en tant que lien dans les autres projets?

Vous pouvez externaliser les chaînes de connexion dans leur propre config, quelque chose comme:

<connectionStrings configSource="connectionStrings.config" /> 

et ont les chaînes de connexion dans ce nouveau fichier:

<connectionStrings> 
    <add name="DataAccessLayer.Properties.Settings.ConnectionString" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=c:\users\something\something\MyDB.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True" providerName="System.Data.SqlClient" /> 
</connectionStrings> 

De cette façon, vous pouvez avoir app.config personnalisé, mais partagent les points communs.

2) Je ne veux pas un chemin complet, quand il s'agit de déploiement qui ne va pas fonctionner. Les chemins relatifs dans app.config ne semblent pas fonctionner.

Malheureusement, la seule chose que vous pouvez faire ici est d'utiliser l'espace réservé |DataDirectory|, qui est un espace réservé pour le dossier App_Data dans une application ASP.NET. La seule autre solution consisterait à utiliser un serveur et à se connecter à un serveur, plutôt que d'avoir des fichiers à monter et à attacher dynamiquement.

+0

thnx pour cela, les solutions connectionstrings sonne idéal – CSharpHolder

4

Utilisation de la fonction chaîne de connexion AttachDbFilename de multiples processus renvoyant le même MDF est très mauvaise idée. Le partage d'une base de données auto-attachée peut vous mettre dans toutes sortes de problèmes complexes de démarrage de base de données de sécurité/possession. Et spécifier User Instance=True est comme verser du gaz sur la flamme, puisque chaque instance d'utilisateur est par utilisateur ainsi si vos applications sont configurées pour s'exécuter sous différents identifiants d'apppool ou si l'une d'elles est soudainement changée pour usurper l'identité, tout se déchaîne. Il suffit de joindre définitivement le MDF en tant que base de données normale à votre instance SQL et de l'utiliser comme tel, avec une chaîne de connexion normall: Data Source=.\SQLEXPRESS;Initial Catalog=<dbname>; Integrated Security=True.

Questions connexes