Two .NET projects, one DB connection string?

Question

I have a .NET solution containing two projects:

• An ASP.NET MVC project, 'Website'
• A class library, 'Models'

The 'Models' project contains a Linq-to-SQL data-context along with a few partial classes that extend the database objects.

The connection string is defined in the web.config of the 'Website' project.

However the 'Models' project seems to have its own app.config where the database connection is defined separately.

This means that if the connection string changes, I'll have to update both projects.

Is there a way I can centralize the connection string to one place, and still have both projects use it?

Answer 1

I'd say that you should keep the configuration of the product in the web project's web.config, and then inject the configuration you use into the model project.

Answer 2

That's fine. Put the Model's connection string in the Web.config and forget (delete) the Model's config file.

The DataContext also takes in a connection string in its constructor so you can specify it this way too (perhaps not on one line though):

DataContext context = new DataContext(ConfigurationManager.ConnectionStrings["TheKey"].ConnectionString);

Edit- based on your comments to other answers it looks like you are doing something wrong. If you are doing that, then the generated code will use the default setting value.

System.Configuration.DefaultSettingValueAttribute("Data Source=SERVER;Initial Catalog=XYZ;Integrated Security=True")].

You might be making the mistake of not specifying the connection string properly in the Web.config file.

Answer 3

Ok, I'm guessing here, but it looks like both projects use an identical connection string, yes?

In that case, only specify the connection string in the web.config; the class library app.config will not be read by ASP.NET anyway.

Answer 4

I think the connection string in the Models library is just used by the designer. During runtime the string is loaded from the web.config. So you do not necessarily need to have the strings synchronised.

Answer 5

Create a partial class that is the same as your data context and use this code to force the usage of the web.config string as opposed to the app.config. Put the partial class in the same location as your model in the class library.

public partial class YourDataContext 
{
    partial void OnCreated()
    {
        ConnectionStringSettings cs = ConfigurationManager.ConnectionStrings["PrimaryConnectionString"];

        if (cs != null)
        {
             this.Connection.ConnectionString = cs.ConnectionString;
        }
    }
}

See this question for more info Preferred Method for connection string in class library
RichardOD posted a link to what I think best describes our problem LINQ To SQL and the Web.Config ConnectionString Value

Answer 6

You don't need the class library app.config. Just put your configuration at the web.config. Also, if you need some configuration section from the library's app.config, just put it on the web.config. The ConfigurationManager will read it from there.

Answer 7

If your Models Class library is referenced in your Web Application, you can simply remove the reference in the App.Config file and make sure you have something similar to that placed in your web. config. That way, when the compiler looks in the web.config, it will find the connection string it needs for the MVC project and hence have no need to look further down for it.

Answer 8

Personally, I extend DataContext in my Respository then do something like:

public ContractsControlRepository()
      : base(ConfigurationManager.ConnectionStrings["AccountsConnectionString"].ToString()) { }

That way my repository can be instantiated and I never worry about setting up a connection, or having to deal with it whatsoever. To change to/from dev/live databases I just change my web.config.

Answer 9

The app.config in the library won't effect production--those connection strings are really there for the linq2sql designer. Nothing to see, move along, these aren't the droids we are looking for . . .