Ideally, you want your LINQ database connection strings defined outside your compiled code and to be held in the Web.Config
Unfortunately, by default, they are added to your Settings.cs
file which is then compiled away into your code. This has the effect of reducing your ability to easily configure your applications for different environments (i.e., you would need to have different compiled DLLs for dev, test and production).
It is also LESS secure because you can easily use reflection to examine your DLLs for passwords - whereas you can encrypt the web.config
so it is only viewable to people who have permissions to the IIS console. This is more difficult to break.
The recommendations to remedy this issue in the following MSDN blog http://blogs.msdn.com/jongallant/archive/2007/11/25/linq-and-web-application-connection-strings.aspx
is slightly wrong. He suggests that you remove the default constructor in the designer. This is bad because you would have to fix up the file every time you regenerate your dbml file. Instead, you should use what is provided to you and set the property on the designer for "Application Settings" to
and also do the following steps every time you will go for the drag and drop your stored procedure and user defined functions.
- Right click on any white space in dbml file.
- Click on properties option.
- Select drop down for Connection option in Properties window.
- Choose last option from drop down for Connection option which should be none.
- Close Properties window and press Save.
This allows you to define a default constructor in your own partial class that extends your dbml context designer classes like example:
using System.Configuration; namespace DMNxtGen.DataAccess
public partial class UserClassesDataContext
: base(ConfigurationManager.ConnectionStrings["WebConnectionString"].ConnectionString, mappingSource)
In the above example,
is the class name of the LINQ to SQL(DBML) file and
is the name of the Connection String in Web.Config