Confused about which .config file is used for ConnectionStrings

Topics: Data Access Application Block
Apr 26, 2007 at 4:30 AM
Edited Apr 26, 2007 at 4:31 AM

I'm just starting up with the Data Access application block (EntLib 3.0) and I need some clarification on how it accesses connection strings.

Let's say my Visual Studio solution is set up with three projects: a Data Access Layer (DAL), a Business Logic Layer (BLL), and a WebClient.

Only the DAL uses the Data Access application block, so I added my connection string to its App.config file, and instantiated a database object as

Database db = DatabaseFactory.CreateDatabase("MyConnectionString");

However, when I ran the solution, the web page (which accesses the BLL, which accesses the DAL) aborted with the message, "The requested database MyConnectionString is not defined in configuration."

I finally found this is the thread that said the solution is to move the connection string to the client: Sure enough, once I moved the connection string out of the DAL and into the WebClient's web.config, I was able to run the solution.

This is rather confusing, since one of the the main purposes of having a multi-tier model is to keep the data access separate from the client.

Why is the Data Access block looking for a connection string two tiers up from where it is used? Have I configured something incorrectly?

Thanks for your help,

Apr 26, 2007 at 9:48 PM
In .NET applications, the .config file is scoped at the AppDomain level, not the assembly level. So no matter how many DLLs you load into the same AppDomain, they will all use the same .config file. By default this is web.config for a web app, and appname.exe.config for a Windows app.

However EntLib gives you a few ways to change the behavior. Take a look at this post for some options.

Apr 27, 2007 at 12:56 AM
Thanks Tom, very helpful. I'm used to the COM+ proxy model for calling DLLs on remote machines. Obviously .NET does things differently.

What would be the most common .NET approach for, say, running the DAL and SQL server on one machine, and the BLL and web server on another machine? Or perhaps running a Windows Forms client on desktop PCs that connects to a BLL on a local server? I know that web services are often used for "long-distance" remote calls. Is there something faster and less cumbersome for calls within the same subnet?