Clean Web.Config Files (VS 2010 and .NET 4.0 Series)

This is the first in a series of blog posts I’m doing on the upcoming VS 2010 and .NET 4 release.

Today’s post is about an admittedly small, but I still think kind of nice, change coming with ASP.NET 4.0: clean, simple, web.config files. 

You’ll encounter this improvement the first time you do a File->New Project within Visual Studio 2010 and create an empty ASP.NET 4.0 Web application (which is why I thought it might be appropriate to-do as the first post).

Web.config files in .NET 3.0 and 3.5

Over the last few releases, the web.config files within new ASP.NET projects have steadily increased in size. For example: the default web.config file that is added to a new web project in Visual Studio 2008 SP1 is now some 126 lines long, and contains everything from tag definitions to definitions of handlers and modules to be included in the ASP.NET HTTP pipeline.

This increase in size is because .NET 3.0 and .NET 3.5 use the same CLR and machine.config configuration file as those shipped with .NET 2.0 – and simply add and update assemblies in the framework when they are installed.  To avoid the risk of us accidentally overwriting customized settings within the original 2.0 machine.config on the machine, we didn’t register the tag definitions, handlers and modules that shipped with the new ASP.NET functionality that came with the .NET 3.0 and .NET 3.5 versions.  Instead, we defaulted to having new projects register these settings within the application’s local web.config file instead.  This was safer – but caused the web.config files to increase and become more complicated and harder to read.

Web.config files in .NET 4

.NET 4 includes a new version of the CLR, and a new .NET 4 specific machine.config file (which is installed side-by-side with the one used by .NET 2, .NET 3 and .NET 3.5).

The new .NET 4 machine.config file now automatically registers all of the ASP.NET tag sections, handlers and modules that we’ve added over the years, including the functionality for:

  • ASP.NET AJAX
  • ASP.NET Dynamic Data
  • ASP.NET Routing (which can now be used for both ASP.NET WebForms and ASP.NET MVC)
  • ASP.NET Chart Control (which now ships built-into ASP.NET V4)

What this means is that when you create a new “Empty ASP.NET application” project in VS 2010, you’ll find that the new default application-level web.config file is now clean and simple:

The first config section above just tells ASP.NET to enable debugging by default for the application, and indicates the version of .NET that Visual Studio should target when it provides intellisense (VS 2010 supports multi-targeting – and the intellisense within the IDE will automatically vary depending on which version of the framework you are targeting).

The second config section indicates whether to use “integrated” mode when running the ASP.NET application within IIS7 – which controls whether to run ASP.NET HttpModules for all requests within the application or just for the ASP.NET specific URLs.  We enable this by default at the application level web.config file for new applications – since for compatibility reasons the default IIS7 setting registered at the machine-wide is to run modules only for ASP.NET URLs (and not for all requests).

Summary

The simplified web.config file in .NET 4 is an admittedly small change – but I think a nice one nonetheless, and one which makes the default experience when you create a new ASP.NET application a little cleaner and more approachable.

In the posts ahead I’ll be delving into many of the more substantial improvements coming with ASP.NET 4. (as well as a few more of the “small but nice tweaks” coming too)

Hope this helps,

Scott

90 Comments

  • Really a usefull change, web config tends to grow too much, and it feels really good to see a small web config.

  • Glad to see a shift to clean config files, the whole reason there are default values for attributes on configuration sections is to keep your config file simple. i.e. only showing the specific configuration options you have chosen that differ from the defaults. The example of messy configuration file is making use of the 'Microsoft Service Configuration Editor' in VS2008, on a WCF service config file it would populate every single default field in existence.

  • You (MS) listened! Thank you.

  • This is great. I was a little annoyed that the web.config was growing in size with every release.

  • This is awesome! web.config files always bugged the heck out of me. VS 2010/.NET 4 is going to rock.

  • This is very great news!

  • Looking great. Excited to play with ASP.NET 4

  • Thanks for letting us get rid of all that crap!
    Next step is to allow to programmatically configure the things that are not enviroment specific and not really prone to change.

  • Thanks for doing this. Reading the old web.config was indeed a hard job and sometimes things got messed up when a line was modified. this should be less error-prone.

  • Great article!

  • That's a very positive development - it'll be great to be able to edit Web.config files without tripping over all the default plumbing.

  • Shortest Gu post. EVER!

  • Seamingly small, but great improvement.

    It will make the life of our sysadmin (who has to roll out the applications) a lot easier.
    And above that it just gives me peace of mind.

  • Scott, I have a challenge, maybe you are willing to try it for beta 3/final web.config:




    PS. Why should I configure Visual Studio with a targetFramework attribute? That should not be in the web.config file, because it's not configuring MY application.

  • cool cleanre move in web.config file...

  • Hi Scott,
    Is there any way in ASP.Net 4.0,that I can tell for some folder turn off specific HttpModules and HttpHandlers ?
    Shail

  • Yes that's really a good step.
    Thanks

  • Really good to hear this. At the moment I have a project with a web.config file that has grown to 234 lines!

  • This is a great change. web.config files were starting to get scary.
    You missed MVC from that list. Was that accidental, or does it signify a lack of MS commitment to MVC in NDP4? Also, how is the \Views\web.config handled in MVC projects? Do we still need one?

  • Thanks for the LIDNUG talk yesterday.

    What will we have to face once we push an existing asp.net 3.5 app on a Win 2008 64bit server with IIS 7 ?
    Will we have to seperate the app pools between .Net 2.0 and .Net 4.0 and 32bit and 64bit and classic and integrated?


  • excellent!

  • Looks good, will MS provide some tool to convert 3.5 web.config to 4.0 web.config which will keep only modifications i made to default web.config?

  • Nice. Bring it on .NET 4.0 series :-)

  • This is a great way to start, Scott.

    Keep 'em coming!

  • It is a good post

    waiting for next posts

  • Nice to have you back, Scott. Love your blog posts!

  • Great post! I began to manage big web.config files and that was not so easy, little and clean config files are a big improvement!
    Thanks.

  • Woot! Nice change to the web.config. A small change but a very welcome one for sure! Thank god for ASP.NET! :D Looking forward to the rest of your .NET 4 / VS2010 series!

  • That is bloody brilliant. web.configs started out as such a nice idea that, as you say, ballooned after 3.0 and 3.5 - it'll be great to have the small, easy-to-handle file once again.

  • Very nice! Hopefully IT Pros will be more willing to dig into the config files now that the bar of complexity has been lowered.

  • This is the most exciting thing I've heard about .NET 4. .NET 3.5 config had me doubting the config file concept, but this makes me a believer again.

  • Excellent post, and nice to have you back, Scott.
    I really missed your blog posts! :)

  • Woohoo! It actually bugs me having to include all the tags in web.config at the moment. This is great news. I'm all for keeping things simpler ;)

  • Hi Scott,
    Great! I look forward to your upcomming posts!

  • Scott,

    I noticed in the example that you have a targetFramework attribute in your config file. Will ASP.NET 4.0 and the .NET 4.0 run independent of .NET 2.0-3.5 or will it do just as it's done in the past and become an extension of the previous frameworks?

  • Wouldn't it be cool if that targetFramework attribute could have a say in how server controls (from pre 4.0) renders markup?

    That way you wouldn't have to resort to using control adapters, renderTable="false" and so on...
    Just generally not having to opt out of undesirable HTML renderings? You know, it would just be nice out of the box.

  • It's good to see that you are paying attention to every aspect of asp.net in this release. web.config was becoming somewhat of a beast and it's good to see that you're simplifying it over there. keep up the good work1

  • Thank you for working on reducing web.config size.
    It was a little disappointing to see bigger default web.config in ASP.NET 3.5

  • Nice. Now all we need is an M-based DSL for writing .config files to make it even cleaner :)

  • Give my thanks to the team for thinking about developer pain points related to web.config. Not having to spend time reading and searching through that file every time I start a project will save my brain some cycle time.

  • .net v4 will be using clr v3? Do you have any good recources on what's changed in the clr for this release? Also (and I hope this doesn't fall under the catagory of "feedback that isn't helpful"), I REALLY don't like the look of vs2010. For some reason it looks like programmer art to me. It really feels like a step backwards in that category to me :(

  • Cool, I've always wanted simpler config files.

  • It was like Christmas in our office when we heard about this change. This is hands-down going to be the best ASP.NET 4.0 feature!

  • Good stuff. To paraphrase other comments, I assume the ASP.NET tab in IIS will have a separate dropdown item for 4.0?

    Welcome back from vavation. I've been enjoying your twitters. Especially about winning the dare...

  • This is nice news:) Thanks

  • Scott,

    Knowing that moving forward with .net changes w/out changing the core CLR (2.0/2.0 -> 3.0/2.0 -> 3.5/2.0) made for a fat .config file. You explain that this is because of custom user changes to the machine.config file and not wanting to mess with that and have breaking changes.

    Does this point to an area where a design enhancement could be made? As the .net framework moves forward these additions would go into a seperate .config file relative to that release. Therefore there might be machine.config for the base CLR and then a machine30.config and a machine35.confg? I understand based on feedback that tracking down what is loaded is a drawback and this only adds to that. That is just another issue that needs a solution where eliminating or combining is not an answer. How about a GUI management tool or something (another topic).

    Just curious if the root cause was addressed. I see upgrading as a benefit by resetting the base CLR and having the new .net separate from the old. What happens though when .net 4.0 start to expand and future packs are added on are back to a fat .config file?

  • Would the compilation/targetFramework attribute work for say a hypothentical version 4.5 based on the 4.0 clr, or would we be back to messy config files again?

  • oh my gosh that's beautiful.

  • "Hope this helps." It might if I could see the image. My company blocks cloud storage sites such as the one hosting your images. Could you host your images someplace safe for access by enterprises that have to be careful about data leakage?

  • Wow! This truly is a very nice change. I love this.


    @ScottGu: .NET 4 includes a new version of the CLR, and a new .NET 4 specific machine.config file (which is installed side-by-side with the one used by .NET 2, .NET 3 and .NET 3.5).


    Hi Scott, can this be done for existing ASP.NET 3.5 applications also by moving these sections and others into the machine.config file?
    ASP.NET AJAX
    ASP.NET Dynamic Data
    ASP.NET Routing (which can now be used for both ASP.NET WebForms and ASP.NET MVC)

    I'm a perfectionist and want to always keep things neat and organized.
    If this is doable for older ASP.NET applications, that'd be great.

    Thanks,
    Soe

  • W00t! Less config is always better - it means defaults have been well thought out.

    Thanks.

  • Thx for cleaning this up. Web.config is a huge angle bracket tax and can easily become a dumping ground. This should help encourage a configs minimal use in favor of convention.

  • Looking forward to more great posts on .NET 4
    Thank you!

  • "ASP.NET Chart Control (which now ships built-into ASP.NET V4)" <-- This is a VERY big deal. Expect to see people using the charting a LOT.

  • app settings and db connection strings should not be part of web.config. Its not easy for the SysAdmin to make changes to web.config file and its more error prone.
    I think this is a welcome news from .NET team

  • What I always liked to have are not one but TWO configuration files:

    One for all the machine independent settings like HTTP handlers, assembly references and all that stuff.

    And another for machine dependent settings like e.g. a reference to the SMTP server, the database connection string(s) etc.

    This would enable more easily manageable deployment scenarios where I would XCOPY the machine independent configuration file to the customer's location while keeping the machine dependent configuration file unchanged.

    Currently I have to manually (or Windiff) the customer's configuration file because it contains both machine dependent and machine independent settings.

  • Great post, nice to see some tidying aswell as adding new features, long overdue and welcome!

    Keep it up!

  • What about App.Configs for WCF that dont restate all the default settings???

  • Hi Scott,

    Is the new CLR with .NET 4 the same as CoreCLR, that shipped with SilverLight3?

    What's the plan to bring the same CLR runtime both on client side(SL3) and on server(ASP.NET)? - if you can reveal this information.

    Thanks

  • Sometimes the smallest things make the biggest difference!

  • So will the new CLR be 3.0? And will I be able to take sites running against the 2.0 CLR and point them to the new CLR in IIS, or will there need to be conversion again as with 1.1 -> 2.0?

  • My understanding is that along with cleaning up the web.config, it has been divided in to two separate file each for debug & release mode....

  • I am not particularly interested on this new web.config file. I like to have quick access too all the configuration settings. This new approach may require us to access the machine.config file more that we used to... nice, but when i get to use it I let you know.

    Thanks...

    The idea of a separate config files, one for each build configuration would be terrific.

  • Thanks but what this feature will bring us is really worthy for the efforts ?

  • @alberto,

    >>>>>> Next step is to allow to programmatically configure the things that are not enviroment specific and not really prone to change.

    That is also coming in VS10 and .NET 4. I'll have a future blog post that covers how to-do that. :-)

    Thanks,

    Scott

  • @shailatlas,

    >>>>>>Is there any way in ASP.Net 4.0,that I can tell for some folder turn off specific HttpModules and HttpHandlers ?

    Unfortunatly Httpmodules and Httphandlers can only be configured at the application level, and not at the per-directory level.

    Sorry,

    Scott

  • @RichB,

    >>>>>> You missed MVC from that list. Was that accidental, or does it signify a lack of MS commitment to MVC in NDP4? Also, how is the \Views\web.config handled in MVC projects? Do we still need one?

    That was the list of configuration sections that have moved up to machine.config. ASP.NET MVC doesn't create any new config sections which is why it wasn't in the list.

    ASP.NET MVC 2 will ship with VS2010 - with lots of good things coming in it too.

    Thanks,

    Scott

  • @Yvan,

    >>>>> What will we have to face once we push an existing asp.net 3.5 app on a Win 2008 64bit server with IIS 7 ? Will we have to seperate the app pools between .Net 2.0 and .Net 4.0 and 32bit and 64bit and classic and integrated?

    Yes - you'll want to have separate application pools for the different versions (both .NET versions as well as for 32bit/64bit configurations).

    Hope this helps,

    Scott

  • @Ajay,

    >>>>>> Looks good, will MS provide some tool to convert 3.5 web.config to 4.0 web.config which will keep only modifications i made to default web.config?

    Yes - when you open a .NET 3.5 project with VS10 it will prompt you to optionally upgrade to .NET 4. If you click yes it will migrate all your web.config settings for you.

    Hope this helps,

    Scott

  • @Matthew,

    >>>>>>> I noticed in the example that you have a targetFramework attribute in your config file. Will ASP.NET 4.0 and the .NET 4.0 run independent of .NET 2.0-3.5 or will it do just as it's done in the past and become an extension of the previous frameworks?

    ASP.NET 4.0 and .NET 4.0 are new versions that run side-by-side of .NET 2.0-3.5. I talked about this a little in a recent post I did on multi-targeting with VS2010.

    Hope this helps,

    Scott

  • @Mads,

    >>>>>>> Wouldn't it be cool if that targetFramework attribute could have a say in how server controls (from pre 4.0) renders markup? That way you wouldn't have to resort to using control adapters, renderTable="false" and so on... Just generally not having to opt out of undesirable HTML renderings? You know, it would just be nice out of the box.

    I'll cover this in a later blog post - but basically you no longer need to use control adapters to get clean HTML markup when you are using ASP.NET 4.0.

    Hope this helps,

    Scott

  • @Amit,

    >>>>>>> Good stuff. To paraphrase other comments, I assume the ASP.NET tab in IIS will have a separate dropdown item for 4.0?

    Yes - IIS will have a separate version dropdown option for .NET 4.0.

    Hope this helps,

    Scott

  • @Some one,

    >>>>>>> Just curious if the root cause was addressed. I see upgrading as a benefit by resetting the base CLR and having the new .net separate from the old. What happens though when .net 4.0 start to expand and future packs are added on are back to a fat .config file?

    We are going to consider adding new expansion pack settings in the top-level config file going forward (at least as an option).

    Hope this helps,

    Scott

  • @lynn,

    >>>>>> Would the compilation/targetFramework attribute work for say a hypothentical version 4.5 based on the 4.0 clr, or would we be back to messy config files again?

    That is our goal. The hope is that we can add both .NET Framework versions and Silverlight versions going forward and easily pick up tool support within VS for them.

    Hope this helps,

    Scott

  • @Matthew,

    >>>>>> "Hope this helps." It might if I could see the image. My company blocks cloud storage sites such as the one hosting your images. Could you host your images someplace safe for access by enterprises that have to be careful about data leakage?

    Sorry about that. I have moved to a different image storage provider for future posts that should hopefully work for you.

    Thanks,

    Scott

  • @Soe Tun,

    >>>>>>> Hi Scott, can this be done for existing ASP.NET 3.5 applications also by moving these sections and others into the machine.config file?

    You can do this manually if you'd like (just edit your root web.config file and set those settings there).

    Hope this helps,

    Scott

  • @Uwe,

    >>>>>>> What I always liked to have are not one but TWO configuration files:

    You should actually be able to-do this if you want. Configuration files support the ability for individual sections to be split out into separate files. So you could pick some settings to separate this way.

    Hope this helps,

    Scott

  • @Kevin,

    >>>>>>> Is the new CLR with .NET 4 the same as CoreCLR, that shipped with SilverLight3? What's the plan to bring the same CLR runtime both on client side(SL3) and on server(ASP.NET)? - if you can reveal this information.

    We share the same code-base between the CLR in Silverlight and the full .NET Framework. The CLR in .NET 4 is a more recent version of the CLR than what shipped in Silverlight 3. It will be used in the next release of Silverlight though.

    Hope this helps,

    Scott

  • @Ankit,

    >>>>>> My understanding is that along with cleaning up the web.config, it has been divided in to two separate file each for debug & release mode....

    Yes - I'll cover this in a future blog post. That is another cool feature :-)

    Hope this helps,

    Scott

  • @Eduyadro,

    >>>>>>>> The idea of a separate config files, one for each build configuration would be terrific.

    Yes - we have that too coming in VS2010. I'll cover it in a future blog post.

    Thanks,

    Scott

  • Hi Scott,

    Thanks for the answer regarding to CLR runtime on SL and server. Currently, the assembly on client SL is not binary compatible with the code on server (asp.net). Is this going to be solved with ASP.NET 4 and next update of SL3, both are supposed to run the new recent CLR 4 runtime?

    Thanks.

  • Will .Net 4.0 support including config files from arbitrary locations as opposed to the current directory or below? For example I would like to be able to do what is shown below. This is disallowed today and it makes deployment a pain especially with different process spaces and/or different virtual directories. I'm sure there were some security concerns as to why this is disallowed, but it it is very painful to manage all these config files because they have to be copied from one directory to the other and kept in sync.

    Here is the use case:



  • My dislike for the web config file has grown with it's size over the years - glad to see that the chaos is being reigned in!

  • Hi Scott, you really should add "previous" and "next" links to your blog ;)

  • It would be cool if app settings could have the external config section file and inline settings which would be merged rather than the current one or the other method. The reason for this is to split the environment varying settings out into a seperate file for version control reasons.

  • This is great to hear. As someone who still prefers to setup projects manually this has been a headache - particularly since not all of the dependencies necessary for each technology are well documented. We usually end up creating a project in VS, then editing down its scaffolding for our own projects. This will help reunite those templates, and make manually creating projects much easier.

  • Hi,

    Nice post. Very nice feature to notice. But there should be a hint saying that these settings were moved into the machine.config.

    Thanks,
    Thani

  • Thanks dear...
    its really good to see compact and not confusing web.config.

    I am expecting more such blogs....

  • Really a Sweet and Short Post.
    A very nice improvement.Handling the Config file gonna be easy!!

  • I really like this change with web.config. I've a question here, What about the settings belong to WCF services. Can I still add and configure my services there?

Comments have been disabled for this content.