Untie LINQ to SQL Connection String from Application Settings

Untie LINQ to SQL Connection String from Application Settings

Did you know that by default LINQ to SQL defines your connection string in more than one place if you define your LINQ to SQL classes out from a web app, such as a data access layer class library?

  1. Under “Application Settings” stored as Settings.settings and compiled in with your code rendering it unchangeable without recompilationand making it very easy to be inspected upon via reflection.
  2. Stored in Web.config / App.config as a reference copy from “Application Settings” in making it very disconcerting as to the true location it is picked up from.
  3. Hard coded in the “.dbml” file of the <Connection /> node as clear text.


Three places?! For standalone web applications it’s not so bad, as it turns out it is still stored in the Web.config and hard coded to the .dbml file, but the connection string is changeable on the fly and it does not store any strings which are baked in.

However if you wish to setup a layered n-tier architecture with your LINQ to SQL classes residing in a separate project, you will suffer the compilation “gotcha”.  Point 1 was a particular problem for me as I needed to update the connection string after compilation with an NAnt build script for deployment to a testing server.  This obviously wasn’t acceptable, as it did not honour changes easily between different database configuration across multiple environments (dev, test, production) so I needed another solution.

Thankfully there was one, and it will shorten that list down (you will still be stuck with a local “.dbml” conn. string copy which appears to pose no deployment implication as it simply tells the LINQ to SQL designer which DB you are working with, which is good).

Remember the below instructions are if you have a separate project holding your LINQ to SQL classes or you your connection string is being compiled into application settings (potentially anything but a Web application?) What we want to do is first turn off application wide settings effectively freeing it from LINQ to SQL: -

  1. Open up the LINQ to SQL designer, and open the Properties tab of the designer (the schema itself), expand Connection and set Application Settings to False. Save.  Don’t you feel better already?
  2. Close that down and open up your DataContext designer file (dbml_name.designer.cs) and alter the DataContext constructor.  You will immediately notice how your connection string decided to jump in here as you turned off application wide settings.  So the part to focus on here is altering the base() inheritor. Renaming “MyConnString” below to suit your own. I also noticed a DatabaseAttribute on the class which I don’t think plays a big part and has any implications on the connection settings. You will also need a reference to System.Configuration:
    
         
         
    1. public dbDataContext() :
    2.      base(ConfigurationManager.ConnectionStrings["MyConnString"].ConnectionString, mappingSource)
  3. Open the App.config or Web.config featured in the project where your LINQ to SQL classes reside, and rename the connection string to what you defined as “MyConnString“.
  4. You now must Cut the entire <connectionStrings /> entry with name change and Paste it into either the App.config or Web.config of the application which is to access the data, such as a web application, Silverlight, WPF, WCF etc.  It is important that you alter the configuration file of the calling application which is to access the data, as the ConfigurationManager defined in your LINQ to SQL classes will look for the .config file from where the calling application is executing from, no matter where your LINQ to SQL classes have been defined.  As you can see, it works a little differently from before.
  5. Now Right Click and open the Properties on your DAL or project containing your LINQ to SQL classes and remove the connection string “Application Setting” reference on the Settings tab.
  6. Rebuild.  You’re all done, now just do a Find in Files check for perhaps your database name that you know was featured in the connection string to check for any stragglers, there shouldn’t be any.


Now you can alter your configuration of App.config / Web.config at your discretion without fear that the connection string is embedded somewhere nasty and won’t be picked up!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值