I've got a system composed of 5 programs. Each application accesses a database using a DAL library. Within the DAL i've an application.config using the following entry:

<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>

While using full path for that attachDbFilename works fine. But I am unhappy:

  1. I've replicated the application.config file into each application that utilizes the database. Easiest way to do this - copying the DAL application.config like a Link within the other projects?

  2. I dont desire a full path, if this involves deployment that aint likely to work. Relative pathways within the application.config don't seem to work. Ideally I must have the ability to pull the DAL from source control onto any computer without having to be worried about altering the bond string every time. This: http://blogs.msdn.com/b/smartclientdata/archive/2005/08/26/456886.aspx discusses DataDirectory for deployment reasons but this does not work with me in debug (unless of course I am utilizing it wrong, see 3)

  3. This can be better like a separate question but it's associated with 2. - It is possible to "good" method of organizing multiple projects for debug? I've produced a Bin dir as well as in each project configurations I copy the dll/exe for this bin dir. I in addition have a copy from the database in here (I attempted no path within the application.config but that did not work either, nor did DataDirectory). Also incredibly annoying is the fact that relative pathways fail to work in DebugWorking Directory setting either, therefore it appears like that's one place that would need to change every time code is examined to a different machine?

Apologies for that war and peace and thanks ahead of time for just about any ideas.

Two solutions - although not really full solutions:

1) I've replicated the application.config file into each application that utilizes the database. Easiest way to do this - copying the DAL application.config like a Link within the other projects?

You can externalize the bond strings to their own config, something similar to:

<connectionStrings configSource="connectionStrings.config" />

after which have individuals connection strings for the reason that new file:

<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>

This way, you could have custom application.config's, but share the commonality.

2) I'm not going a complete path, if this involves deployment that ain't likely to work. Relative pathways within the application.config don't seem to work.

Regrettably, the only real factor that you can do here is by using the |DataDirectory| placeholder, the industry placeholder for that App_Data folder within an ASP.Internet application.

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

The only real other solution is always to make use of a server and fasten to some server - instead of getting files to dynamically mount and fix.

While using connection string AttachDbFilename feature from multiple processes mentioning the same MDF is very bad idea. Discussing a car-atached database can enable you to get in most kind of complicated security/possession database startup problems. And indicating User Instance=True is much like flowing gas within the flame, since each user instance is per user therefore if your programs are ever set up to operate under different apppool qualifications a treadmill all of a sudden is transformed to impersonate, all hell breaks loose.

Just attach permanently the MDF being an normal database for your SQL instance and employ it as a result, having a normall connection string: Data Source=.\SQLEXPRESS;Initial Catalog=<dbname>; Integrated Security=True.