Searching for flexible way to specify connection string used by ASP.NET membership

I develop an asp.net web application and I use ASP.NET membership provider. The application uses the membership schema and all required objects inside main application database However, during development I have to switch to various databases, for different development and testing scenarios. For this I have an external connection strings section file and also an external appsettings section, which allow me to not change main web.config but switch the db easily, by changing setting only in appsettings section.

My files are as below:

<connectionStrings configSource="connections.config">
</connec开发者_运维百科tionStrings>

<appSettings file="local.config">
    ....

ConnectionStrings looks as usual:

<connectionStrings>
  <add name="MyDB1" connectionString="..." ... />
  <add name="MyDB2" connectionString="..." ... />
  ....
</connectionStrings>

And local.config as below

<appSettings>
    <add key="ConnectionString" value="MyDB2" />

My code takes into account to use this connection string

But membership settings in web.config contains the connection string name directly into the setting, like

<add name="MembershipProvider" connectionStringName="MyDB2" ...>
....
<add name="RoleProvider" connectionStringName="MyDB2" ...>

Because of this, every time I have to edit them too to use the new db.

Is there any way to config membership provider to use an appsetting to select db connection for membership db? Or to "redirect" it to read connection setting from somewhere else? Or at least to have this in some external file (like local.config)

Maybe is some easy way to wrap asp.net membership provider intio my own provider which will just read connection string from where I want and pass it to original membership provider, and then just delegate the whole membership functionality to asp.net membership provider.

---

I found this solution to create inherited classes and override the Initialize() method to change the connection string. Worked well for me but the web.config settings can be a little tricky. I ended up having to create both a SqlMembershipProvider and a SqlRoleProvider.

http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataproviders/thread/260d8536-c39f-41ec-b181-4d452cf054b3

---

I use different external configuration files for connection strings in this situation. Possibly (depending on your concrete situation) you can use Visual Studios pre build events to copy the files to the right places.

---

Actually, after some more thinking, I found a solution for my problem.

My initial thought was to set specific connection string name in local.config, which will point to a connection string in conenction string sections. But with this approach I had to change connection string name also in membership-related settings

The new approach which helped me to have a single reference to connection string (to be used by botrh my DAL and membership) was the following:

1. in web.config I have a setting which is used by my DAL, which store the name of the connection string:

   <add key="ConnectionString" value="ManagDB" />

2. membership-related settings have reference to the same connection string

   <add name="MembershipProvider" connectionStringName="ManagDB" ...>
   <add name="RoleProvider" connectionStringName="ManagDB" ...>

Web.config will be tyhe same for all instances of my appliucation, so no change is needed in it

3. I extract the connections strungs into an external file, with this setting in web.config

   <connectionStrings configSource="connections.config"> </connectionStrings>

4. Then I define the specific connection string for a certain instance in file connections.config

   <connectionStrings>
   <add name="MyDB" connectionString="Data Source=..." providerName="System.Data.SqlClient" /> </connectionStrings>

Using this approach I was able to have a single, unchangeable web.config specific to the application, common to all instances, and then specific connection string to a certain instance which allow both DAL and membership to use the same database