Newbie: Connection strings in both app.config and Linq to SQL DBML

nhwilly posted on Monday, July 20, 2009

I am using the ProjectTracker as a guidepost, but actually developing my app (ScoreBoard) one step at a time to make sure I understand the innards.

So I created the DBML for the Linq to SQL library (ScoreBoard.DalLinq) and I noticed it created a connection string in that app.config file. That makes sense, it'd have to.

Then I created a Windows forms project that uses the BO from ScoreBoard.Library (which references ScoreBoard.DalLinq). It needs a connection string, too and it puts one in the SBWin app.config file.

I presume I haven't messed up and actually both of these are necessary, at least one for the DBML to function and one for the resulting app to function.

When I actually publish the app, does the app.config from the DBML actually get used? Does it get included in the code?

In the end, I was hoping for just one connection string in the deployed application.

I've read about this on the web, but not in reference to CSLA.

Can anyone shed some light on this?

TIA

RockfordLhotka replied on Monday, July 20, 2009

Sometimes Visual Studio creates config files for Class Library projects, but they are just for illustration.

The only config file that ever matters is the one associated with your EXE or your web folders. Never does a config file for a DLL get used.

(never - ha! It turns out that nunit does some clever trickery to use a config file for your test DLL - but that's absolutely abnormal and is unique to nunit)

nhwilly replied on Wednesday, July 22, 2009

Thanks, Rocky.

 

I haven't tried to deploy anything yet, so I couldn't tell.

 

At least now I can stop looking.

 

You know you're going to guilt-trip me into buying your SL videos, right?

 

:)

RockfordLhotka replied on Wednesday, July 22, 2009

ajj3085 replied on Thursday, July 23, 2009

Actually....

There is another case. When you create an Office add-in, you can have a config file for your assembly. The same naming conventions apply (assembly.dll.config). I've done this actually, to build an add-in which uses Csla and a remote dataportal as well!

All I did was have MSTO installed for VS, created a new Outlook Add-in project, and then told it to add an App.config file. VS took care of the rest, and the build will name the .config file properly, and an installer project will include it when your plug-in is installed.