Connection string hell in .NET / LINQ-SQL / ASP.NET

Question

I have a web application that comprises the following:

• A web project (with a web.config file containing a connection string - but no data access code in the web project)
• A data access project that uses LINQ-SQL classes to provide entities to the web project UI (this project has a settings file and an app.config - both of which have connection strings)

When I build and deploy, there is no settings file or app.config in the Bin directory with the data access .dll, but changing the connection string in the web.config file doesn't change the database accordingly - so the connection string must be compiled into the data access dll.

What I need is one config file for my entire deployment - website, data access dlls, everything - that has one connection string which gets used. At the moment there appear to be multiple connection strings getting used or hardcoded all over the place.

How do I best resolve this mess?

Thanks for any help.

Answer 1

I've never had a problem with the Data Access Layer (DAL) being able to use the connection strings from my web.config file. Usually I just copy the connection strings section from the DAL and paste it into the web.config. I'm using the DBML designer to create the data context.

If this won't work for you, you can specify the connection string in the data context constructor. In your web project have a static class that loads your settings, including your connection strings, and when you create your DAL object (or data context, if creating it directly) just pass it in to the constructor.

public static class GlobalSettings
{
    private static string dalConnectionString;
    public static string DALConnectionString
    {
       get
       {
           if (dalConnectionString == null)
           {
              dalConnectionString = WebConfigurationManager
                                      .ConnectionStrings["DALConnectionString"]
                                        .ConnectionString;
           }
           return dalConnectionString;
       }
    }
}
...

using (var context = new DALDataContext(GlobalSettings.DALConnectionString))
{
   ...
}

Answer 2

The configuration file for the startup project will define the configuration settings for all included projects. For example if your web project is the startup project, any reference to "appSettings" will look for settings from web.config, this includes any references to "appSettings" from your data access project. So copy any config settings from the Data Access project's app.config to the web project's web.config.

Answer 3

Roll your own ConnectionFactory based on the Registry:

• add a registry key for your application under SOFTWARE/[YOUR_COMPANY]/[YOUR_APP]
• add a string value for ConnectionString
• Teach your ConnectionFactory to crack open the appropriate registry key (in a static constructor, not every page load!).
• export the registry info as a .reg file, add it to source control, modify and apply it as necessary to set up additional machines.

Pro:

• Simple to set up
• Connectionstring lives in a single place
• Not in web/app.config, so no need to hardcode environment-specific settings.
• Not in web/app.config, so Junior Dev Jimmy can't accidentally tell your production server to look at the DEV database

Con:

• Not immediately obvious that important things are living in the registry, so new devs will need instructions.
• Extra step when configuring a new deployment machine
• Registry is oldskool. Junior devs will mock you.

Answer 4

Thanks for the responses.

Those of you who say the app will use the setting in the web.config are correct for instances where I reference it in my own code:

_connectionString = ConfigurationManager.AppSettings["ConnectionString"];

..but there is a different issue with LINQ-SQL datacontexts - I think they include connections strings in the compiled dll for use in the parameterless constructor. As tvanofosson says, I need to create datacontexts by passing in a reference to the connection string in the web.config. Which is where I was getting into a tangle :)