I ran into a problem with using LINQ when deploying code to different environments, when the dbml and the web code were in separate assemblies. After doing some research I ran across the following blog by Rick Strahl: LINQ To SQL and the Web.Config ConnectionString Value
It's a good read, and really helped me understand what's going on under the hood with the LINQ connections. Anyway, I ended up writing a partial class that allowed me to keep the nice default constructor with LINQ DataContexts, and also use a simple connection string in the web.config file.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace WebProject.Data
{
public partial class WebProjectDataContext
{
public WebProjectDataContext() :
base(System.Configuration.ConfigurationManager.ConnectionStrings["WebProjectConnectionString"].ToString(), mappingSource)
{
OnCreated();
}
}
}
You'll need to change your LINQ classes' DataContext Properties so that it doesn't read from the app.config file (set connection to NONE). That will keep LINQ's code generator from creating the default constructor. You can then place a partial class like the one above in the assembly. LINQ will then use your web.config's ConnectionString when creating the DataContext with the default constructor.
View Trenton Adams's profile