Web.config values passed through tiers

Question

I have a .NET 2008 solution with a project that acts as WCF Service host. That project has a web.config file with settings that will be replaced by the installer when the project is complete. Those setting are components that make up the connection string and a few others.

This WCF project references a Business Logic project(class library which implements service code) which in turn references a DAL project which uses the Entity Framework.

What I would like to know is how can I get the values in the web.config in the WCF project to the DAL? Without using any relative paths that I have seen with OpenMappedExeConfiguration. I need to build up the connection string in the DAL based on the setting in the web.config file.

Thanks for your answers.

Answer 1

I`m storing shared things like connection strings in 1 folder, which even is not under folder where source code lives. In DAL tier i just use ConfigurationManager to pick it up.

In project, which starts application (in your case, it`s WCF project), i add "ConnectionStrings.config" file from my external "config" folder AS A LINK (in visual studio, press 'add an existing item' -> choose item -> next to "Add" button is an arrow where this option lives). Then i just set it through that file properties (click on file in solution explorer -> press F4) as a content of project and that it should be copied once again if modified to deploy folder. Then i add a new app.config file to project, which includes "ConnectionString.config".

Source of connectionstrings.config:

<connectionStrings>
  <add name="MyConnectionString"
     connectionString="Data source=tralala"/>
</connectionStrings>

Source of app.config in WCF project:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <connectionStrings configSource="ConnectionStrings.config"></connectionStrings>
</configuration>

I'm not sure that this is the best approach. But so far so good.

Answer 2

Unfortunately, the answer to your question is "copy and paste". This has always been true.

The closest thing to an exception to this rule is the "new" .NET 2.0 Settings files. Because the structure and default values for these are part of the assembly defining the component, the component can, upon startup, cause the default values to be written to the applications configuration. I imagine one could couple that with a piece of code to work with installutil to cause the defaults to be written out before the containing application is ever started, leaving the defaults in the config file to be edited before the application is used for the first time.