4 Answers
4

I've never heard of anyone making web.config accessible and writable to customers or any other business folk. You're just asking for trouble.

It sounds like you may want to develop a small front-end (web) utility to allow them to submit values in a form and save to a database. Then have your application access the database for these values, and not the web.config.

Split your configuration file into two. One for you and the other for your customers.
All configurations that are customizable by your customers go into the customer config file and everything else goes into yours.

This will let you easily upgrade/modify your config file without overwriting your customers'.

There are a few ways to handle this. I'll mention two. One concerns your delivery process. The other actually involves the web.config.

1) Don't ship the web.config as "code". Consider it "configuration". This doesn't apply well to all scenarios (in fact, a customer based scenario is the bad scenario I was thinking of). If you are delivering to "production" you can agree to make them responsible for the contents of web.config (and a good practice there is to try and refactor as much as you can to machine.config). That way, things like the connection string become production concerns and not development concerns.

2) Use the configSource attribute. ASP.NET 2.0 supports externalizing attributes with the configSource attribute. It can be hard to turn over ALL of the web.config as a "production concern" (in a delivery to customer scenario, They may not be experts in all of this).

So you externalize it like this. Here is your current appSettings section, for example:

Only one possible problem with this; there can only be one config source per section. It does allow you to compartmentalize, but if you're adding one AppSetting to a list of existing, possibly changed appSettings, you're still blowing away some of their config settings by publishing the compartmentalized file.
–
KeithSFeb 17 '11 at 19:52

You have a couple options. The best, IMO, would be to not publish web configs when you push the app to their environment. If a new configuration section/setting needs to be written, you can either encapsulate some logic to programmatically write the new config in a little helper app and run that as a post-deployment action, or you can just paste the new settings into an e-mail and send to someone you trust on the other end to put it in the configs. I would recommend against the second option in 99% of cases; there is a lot of potential for crossing wires or just being ignored, then it's your fault when the system goes down because the configs didn't make it in.