1

I have an asp.net project that is using Entity Framework that is used on several different client servers. This means a different web.config for each for connectionstrings and app settings. Hasn't been an issue but I changed something that altered the web.config file recently and I manually had to adjust this for each client, I also have to exclude the web.config file in updates to ensure their own one is not overwritten.

What I would like to achieve is store these settings in maybe another config file that the project can pick up and use. Maybe that on Globals Application_Start gets these and imports them/overwrites the current web.config file perhaps.

Essentially I don't want to affect the current code that uses the connection string and ConfigurationManager.AppSettings used throughout the project but I do want to be able to let the web.config file update for each client and use a seperate file for some settings.

NOTE: I do not have access to publish directly to each server so I can't simply write a different deploy web.config for each one. I have to publish the files locally, store as zip and automated routine on servers downloads and extracts accordingly.

EDIT: Please do say if this is considered a bad idea but an idea I had was to put something similar in Global.asax Application_Start method:

  1. Does config file exist?
  2. If no, create file and append all current settings in web.config
  3. If yes, open and import those settings to the current web.config overwriting the original values

Hopefully then in a few weeks time, after I have asked all clients to perform a manual update they will have this code and I can begin to include the web.config in updates.

user1166905
  • 2,612
  • 7
  • 43
  • 75
  • 1
    There's nothing forcing you to use web.config to store settings, it's just a handy convenience. Put it in another file, database, registry, grab it from web service etc. – DavidG Oct 06 '14 at 13:04
  • 1
    You can split into a main web.config and additional .config files different per client using the `file` and/or `configSource` attribues. See [this question](http://stackoverflow.com/questions/6940004/asp-net-web-config-configsource-vs-file-attributes) – Daniel J.G. Oct 06 '14 at 13:07
  • With EF though the connectionstring name is named the same as the dbcontext and this links perfectly. I don't want to lose this link or app settings. Can these be overwritten by the project? – user1166905 Oct 06 '14 at 13:07
  • @DanielJ.G. That would work. The issue there though is it requires a web.config change so manual changes again plus those config files would need to be excluded from the update so client ones are not overwritten. I'm aiming to change this without disrupting the clients end. – user1166905 Oct 06 '14 at 13:10
  • Made an edit to the question – user1166905 Oct 06 '14 at 13:23
  • "I do not have access to publish directly to each server so I can't simply write a different deploy web.config for each one" Well, there's your problem. Unless you require direct physical access to install anything on the server, I'd find a way to automate this process. what if, in 5 years and 100 extra customers, someone finds a serious bug in a shared DLL and you need to go and update them at all your clients? – Nzall Oct 06 '14 at 13:34
  • @NateKerkhofs The update process is automated, the issue is updating the web.config file despite each having different database connection strings and app settings. – user1166905 Oct 06 '14 at 13:36

1 Answers1

1

In VS, inside the Build menu, the last item is Configuration Manager.

In here you can specify various different release environments which can each have their own web.config transforms.

This is normally used for production/staging/test environments. However, I can see no reason why you could not use this and have a configuration file for each of your servers/environments.

You will then need to create the transformations for each environment, by rightclicking the web.config, then selecting Add Config Transform.

each of the environments you had setup can then override the settings in the main web.config. (That now acts as a template/default settings)

e.g. In Web.EnvironmentA.Config

<add key="ConnectionString" value="ConStringA" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>

In Web.EnvironmentB.Config

<add key="ConnectionString" value="ConStringB" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>

Then when you do a publish, you simply setup which config file to use. If you use Azure or the VS publish method, it will save each of these settings, so then you can simply push to the relevant environment easily.

Just make sure you test this works as you intent first, before you start publishing everywhere ;)

Del
  • 416
  • 2
  • 13