Comments on: Untie LINQ to SQL Connection String from Application Settings

By: Jeremy Bunga

Jeremy Bunga — Mon, 12 Sep 2011 16:06:24 +0000

Many thanks!

This was very helpful and saved a lot of headaches. Thanks!

By: Mariano Barroumeres

Mariano Barroumeres — Mon, 22 Aug 2011 03:11:36 +0000

I’m not a LINQ to SQL pro, but why don’t you just use the DataContext constructor which takes the connection string as a parameter? It’s already auto generated by the designer in the Whatever.designer.cs

public WhateverDataContext(string connection) :
base(connection, mappingSource)
{
OnCreated();
}

I mean, OK, you’ll probably forget to delete the ‘plain’ CS for your developing machine from time to time if sth has changed in your designer, but if you just need to use dynamic database credentials use the constructor provided for that.
There are 5 constructors for the DataContext, there has to be one that fits your needs.
Kind regards, Mariano.

By: Eric

Eric — Tue, 09 Aug 2011 16:18:07 +0000

Over the past 3 days I’ve had a slew of issues deploying an MVC project to IIS because I naively expected the Linq to SQL class builder to play nice. I changed my web.config and app.config, but kept getting a cryptic “can’t connect to database” error. After 2+ days of fruitless Googling, I finally discovered that my local connection string (using my local machine name) was hard-coded into the SQL classes. No wonder the production server couldn’t establish a connection!

I fixed all of the hard-coded references, but doing a massive search/replace every time I built was a pain. Your solution is far more elegant. Now I just need to manage my application’s web.config and my DAL’s app.config, both of which can be handled with XDT transformations tied to my build process.

Thank you for putting together an excellent resource!

By: Harshil Shukla

Harshil Shukla — Thu, 30 Jun 2011 09:43:36 +0000

Hi,
Thanks a lot for this solution!!!
I have made my site working properly.
I have used only two steps of your solution and it is working fine now.

By: Aaron Clausen

Aaron Clausen — Wed, 16 Mar 2011 04:19:25 +0000

Jon’s solution is the best.

I have been using the solution at the top of this blog article for many months, but it became quite dangerous in a production environment, because occasionally I would rebuild and deploy the project without remembering to change the designer.cs file. Then suddenly production is down because it can’t find the database.

With Jon’s solution, the partial class remains totally intact permanently, even after you make any desired edits to the DBML designer. No problem, because the partial class is in a separate file and stays there regardless.

The trick is “removing all the connection gook” which eliminates the “member already declared problem”.

Thanks Graham for raising an important topic with a solid solution and Jon for putting the icing on the cake.

Now I have zero issues with this and can deploy to production any time fear free, my connection strings just *work* !

By: PdeBie

PdeBie — Fri, 11 Mar 2011 16:38:33 +0000

Thank you for this solution. I had exactly the same problem with my 3-tier application.

On my local computer everything worked fine, but when I changed the connectionString on the test server it couldn’t make the connection (because test server was in different network).

Thanks again! I’ve saved this page to my favorites.

By: Joe

Joe — Tue, 08 Feb 2011 20:24:15 +0000

I am using this but sqlMetal stomps it. Anybody know where \ what file “Application Settings = Flase” is kept in?

By: Don Wilcox

Don Wilcox — Tue, 11 Jan 2011 16:30:12 +0000

Thanks for the original post and follow-ups. I was able to get it to work using the partial class method, with one additional step: every time I add a table to the designer, I have to go in and remove the static connection string from the DataContext properties window. A bit of a pain, but not a horrible one, especially given the benefits of having the connection string out of my data layer.

By: Fu

Fu — Thu, 18 Nov 2010 16:26:53 +0000

Great step by step, my friend..! Just as what I need. Really helpful

By: richard henwood

richard henwood — Wed, 06 Oct 2010 12:37:58 +0000

why not just comment out the constructor for the DBML that has no connection string argument,
i.e.

Public Sub New()
MyBase.New(……)
OnCreated
End Sub

since it is the one that uses application settings and the other constructors use the connection string. instead of complicating your life.

Ritchieh.sd