.NET 4 web.config file refactoring - what's the value?

Question

According to what's new in .NET 4: "major configuration elements have been moved to the machine.config file, and applications now inherit these settings."

I'm on a project upgrading from .NET 3.5 to .NET 4, and I have some questions about this change:

I assume this change is optional: if I leave my current web.config file as-is, it should run just fine under .NET 4 - correct?
This enhancement seems to have dubious value: the config hasn't been simplified - the complexity/bloat has just been relocated to the machine.config file instead of web.config. Am I missing something?
It seems like this enhancement actually makes deployment more difficult: in addition to the deployment steps we already had, now we also need to modify the machine.config file to ensure it contains our expected settings/values.

As you can see, my initial take on this is: it's a hassle and I don't want to do it. Is there some perspective I'm missing that makes this change especially useful and valuable?

EDIT: Nathan and Rob - both your answers were very helpful and greatly appreciated - it was difficult to decide which to flag as the "real" answer. I upvoted both, of course. Thanks again!

possible duplicate of [Clean Web.Config file in Asp.NET 4.0?](http://stackoverflow.com/questions/2799213/clean-web-config-file-in-asp-net-4-0) — David, Feb 17 '11 at 22:46
@David - I did look at that post, but it seemed more focused on the mechanics of web.config vs. machine.config. I'm more interested in the subjective value of the change, its impacts on upgrading from 3.5, and impact to deployment processes. It's always good read related postings (sometimes SO search doesn't find what you need). Thanks for the pointer! — mikemanne, Feb 17 '11 at 22:51

Rob · Answer 1 · 2011-02-17T22:54:22.917

From my perspective, the web.config grew and grew between .net 1.0 and .net 3.5 as "stuff" was incrementally added to it. By the time we hit .net 3.5 it was chock full of things that I never used or modified. Yes, it was needed by the asp.net runtime, but that's not my problem!

Unless you've specifically changed a setting that's been migrated to machine.config for one of your applications, there's no need to re-create it in your web.config. In other words, by shifting all the defaults that were added in .net 1.1 -> .net 3.5 from every web.config created by Visual Studio, ever to machine.config, Microsoft have made the file cleaner and easier to read. A classic example is this:

<sectionGroup name="System.Web" type="System.Web.Configuration.MicrosoftWebSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
  <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
    <sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
      <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false"/>
      <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false"/>
      <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false"/>
    </sectionGroup>
  </sectionGroup>
</sectionGroup>

All that mess can be found in a Visual Studio 2008 generated web.config, but it's not present in a Visual Studio 2010 generated web.config as it's been moved to machine.config where it belongs (but couldn't be moved to in .net 3.0 / .net 3.5 as they still ran on the .net 2.0 CLR).

Thanks to the fact that these were seldom changed, upgrading a project to .net 4.0 and "cleaning" the web.config file should cause no issues. Leaving the redundant configuration in the upgraded projects web.config file should also make no difference as the values in the web.config will simply override the values from the machine.config.

score 2 · Accepted Answer · answered Feb 17 '11 at 22:49

You don't ever need to modify the machine.config unless you want those settings to be the default for all applications running on the server.

Most of what was moved out of the web.config were "boilerplate" config items that were added with the release of .NET 3 and 3.5. They were needed by ASP.NET to register controls, handlers, etc, but rarely were they things you would actually need to modify, or care to.

So basically this is useful to you because the configuration items that are just "white noise" to you are now moved out of you way, allowing you to focus on the settings you actually want to manipulate.

ScottGu discusses this subject in a blog post of his: http://weblogs.asp.net/scottgu/archive/2009/08/25/clean-web-config-files-vs-2010-and-net-4-0-series.aspx

.NET 4 web.config file refactoring - what's the value?

2 Answers2