web.config best practices when upgrading

I send out an ap开发者_JAVA百科p and I let customers make changes to connection strings and such in the web.config.

When I upgrade my app this causes an annoyance because I don't want to overwrite their values with mine.

This is especially bad when versions of .net are upgraded.

How do people typically handle this type of situation?

For example do they somehow split the web.config out so the customer data is no longer part of it?

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.

This seems to be more of a content management issue.

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'.

You can use the SectionInformation.ConfigSource element to declare associated configuration files. This blog post shows you how you can do it.

I even used it in this project to detect changes to external configurations in ASP.NET.

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:

<appSettings>
  <add key="EnableFrobbing" value="false" />
  <add key="ExpectFooingFrom" value="fooingserver@domain.com " />
</appSettings>

If these are settings you want to externalize so your new shipments don't override customer settings, replace it with this:

<appSettings configSource="App_Data\WebConfigXML\appSettings.xml"/>

Relative paths only here as far as I know.

References:

(Shows the property is new in ASP.NET 2.0) http://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.configsource%28v=VS.80%29.aspx

http://www.codeproject.com/KB/aspnet/Manage_Webconfig.aspx

http://trycatchfail.com/blog/post/2008/09/25/Webconfig-magic-configSource-and-file-attributes.aspx

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.