By default, creating a new LINQ to SQL model (.dbml) will put the connection strings in both the application settings file and also web.config / app.config. This is not so much of a problem for web projects, but what about class library projects? Personally I would rather just define my connection string once, in web.config.

To achieve this, first you need to change your Data Context so that the connection string is not stored in an Application Settings file. Open up your DBML and click the designer service. Expand the Connection property and set “Application Settings” to False.

Doing this hard codes your connection string in the default constructor of your DataContext. If you open up .designer.cs you will see something like:

public AdventureWorksDataContext() :
 base(“Your connection string”, mappingSource)
{
 OnCreated();
}

To retrieve the connection string from web.config you could simply change this constructor to:

public AdventureWorksDataContext() :
 base(ConfigurationManager.ConnectionStrings[“Linq2SqlConnectionString”].ConnectionString, mappingSource)
{
 OnCreated();
}

Or better yet, create a new partial class that extends your data context. To do this you will need to remove the default constructor from the generated designer code and add this to your new partial class.

Whilst both methods will work (as far as grabbing the connection string from web.config), as soon as you make any changes to your DBML through the designer, your Data Context constructor will be reset and you will likely get compilation or runtime errors.

My preferred solution is to create a custom Data Context class that inherits from the generated Data Context:

    public class DB : AdventureWorksDataContext
    {
        public DB()
            : base(ConfigurationManager.ConnectionStrings[“Linq2SqlConnectionString”].ConnectionString)
        { }
    }

Then I just work with my custom Data Context in my data access layer

        public IQueryable Customers()
        {
            DB _db = new DB();
            return _db.Customers;
        }

I can also change my Data Context as much as I like without breaking anything.

One thing worth noting is that even with the above method your connection string is still present in the default constructor of the generated data context class. If you are selling your assembly or perhaps including it in a public project, you may want to change this.