ConfigSource Your Rewrite Rules

By January 24, 2017.NET, ASP.NET, Web

When your Web.Config Gets too Big

Maintaining a web.config in your ASP.NET application can quickly get out of hand. It contains the bulk of your web application’s settings and configurations, and even the fresh, out-of-the-box version is several hundred lines long. If you have a set of IIS URL Rewrite Rules to maintain in the same file, the web.config can become immense. This is where using configsource can come in handy.

Benefits of ConfigSource

In my view there are some large advantages to separating your list of rewrite rules out from the web.config file into a separate, configsource-appointed config file. The first is the above-mentioned maintainability of the web.config. Rather than letting the web.config grow in size, doubling depending on the complexity of your rewrite rules, you only add a few lines one time (the configsource instruction) and never have to delve into the web.config again.

The second major advantage is that you no longer have to concern yourself with restarting your web application just because you wish to update a rewrite rule. By default. ASP.NET web applications watch certain files and folders for any changes, and trigger an automatic restart if any of them are touched. The web.config file is one such file. When you have your rewrite rules as a configsource entry instead of being inlined within the web.config, you can change the rules as much as you like without having to restart your application one or more times. And if you do want to restart, you’re still free to do so anyway. But the choice is now in your hands.

Separation of concerns is another plus to using configsource. The web.config file has a lot of responsibilities and reasons to change as it is (major no-nos when trying to adhere to SOLID principles. With configsource, you can have a file whose sole responsibility and reason to change is to maintain IIS rewrite rules, and the web.config can happily pass that responsibility along to the latter.

Enabling ConfigSource for Rewrite Rules in your Web.Config

Setting up your web.config to have rewrite rules using configsource is incredibly simple. Take this segment of a web.config that has some rewrite rules in it:

To separate your rules out, leave the XML within , but remove all of its contents and make it a self-closing tag. Add a “configSource” sttribute and specify the name of the file where your rules will live going forward.

This file will be on the same level as the web.config.

The configsource-appointed rewrite.config file exists on the same level as the web.config file in your file system.

Within your new config file, simply specify the rules as they would have been in the web.config originally. The following sample is the entire contents of the new rewrite.config file.

Now you have a nice separation of concerns setup, and are no longer beholden to having to edit the web.config file whenever an IIS rewrite rule needs added, modified, or removed.

ConfigSource for Other Web.Config Elements

As a brief mention, the rewrite rules section of the web.config is not the only one you can use configsource with! Many, many other sections in the web.config support this feature, and you can read more about configsource in general at Microsoft’s documentation page.

The following two tabs change content below.
Scott has been working with .NET and web technologies for several years, having developed many applications and web sites. He's an experienced developer, well-versed in many flavors of ASP.NET and C#, SQL, JavaScript, and even some CSS. He loves to solve problems, and is a major proponent of Test Driven Development. In recent years, he's become experienced in Telerik's Kendo UI and Sitefinity products.