When working on large projects whether it be websites or software applications, I like to try and make sure that settings from within my app/web configuration files are not only easily accessible within code, but also maintainable for future updates.
Over the years, I have tried different approaches in an attempt to streamline how I use ASP.NET's configuration files within my day-to-day development and this is what I currently do.
Group and Alphabetise
I have started to sort all my settings alphabetically and group common functions/settings together. This alone makes navigating through a large configuration file much more easier.
In addition, having a standard in-house development style and agreeing with your fellow developers how sections within the configuration file is expected to be structured can be useful. For example, on web projects I've worked on, all key sections are sorted in the following order:
- configSections
- appSettings
- connectionStrings
- system.web
- customErrors
- system.webServer
- locations
Common Naming Conventions
I like to name my appsettings in the following format: "<Setting-Group>.<Name>". So if I were to add appsettings that related to Twitter, it would look something as the following:
<add key="Twitter.ApiUrl" value="https://api.twitter.com/1.1/statuses/show.json" />
<add key="Twitter.ApiKey" value="" />
<add key="Twitter.ApiSecret" value="" />
<add key="Twitter.AccessToken" value="" />
<add key="Twitter.AccessTokenSecret" value="" />
<add key="Twitter.Username" value="shomra" />
This provides a simple and descriptive approach to breaking down all settings into manageable chunks.
Strongly-Type AppSettings
One thing that truly annoyed me when I first started .NET development is calling configuration values from within C# code. Not only did you have to write out (the very long-winded!) "ConfigurationManager.AppSettings["Twitter.Username"]", but also cast the value to a specific type.
Using the "ConfigurationManager.AppSettings[]" call is awful. It creates the potential for typo's that aren't caught by the compiler and there's no nice intellisense to make our coding easier.
I create a static configuration wrapper class to strongly-type all my config settings. The way I name my settings (as you can see from the "Common Naming Conventions" section) compliments the structure of my wrapper class.
public class Config
{
public static class Social
{
#region Twitter
public static class Twitter
{
public static string TwitterApiUrl
{
get
{
return ConfigurationManager.AppSettings["Twitter.ApiUrl"];
}
}
public static string TwitterUsername
{
get
{
return ConfigurationManager.AppSettings["Twitter.Username"];
}
}
public static string TwitterApiKey
{
get
{
return ConfigurationManager.AppSettings["Twitter.ApiKey"];
}
}
public static string TwitterApiSecret
{
get
{
return ConfigurationManager.AppSettings["Twitter.ApiSecret"];
}
}
public static string TwitterAccessToken
{
get
{
return ConfigurationManager.AppSettings["Twitter.AccessToken"];
}
}
public static string TwitterAccessTokenSecret
{
get
{
return ConfigurationManager.AppSettings["Twitter.AccessTokenSecret"];
}
}
}
#endregion
}
}
Admittingly, this can be quite time-consuming but when compared to the long-term benefits this has saved me a lot of headache.
What Else Could Be Done?
I've seen some developers use Applications Settings Architecture within the .NET framework when building Windows applications by creating a "Settings" file within the project.
The only downside I can see with this approach is that all config values declared within the "Settings" file will be compiled at runtime and you lose the flexibility to change configuration values externally. Here's a nice StackOverflow post that describes this method in greater detail.
If any of you readers have further suggestions or advice, I am all ears! :-)
The Future...
As Nick Dyer quite rightly pointed out to me yesterday on Google+, that our beloved web.config file will no longer form part of the applications we create in ASP.NET 5. We will have the freedom to create an applications configuration the way we want, simplifying the whole process.
As I understand, there will be support for creating configuration inputs that can be placed inside JSON, XML and INI files using the new IConfiguration and ConfigurationModel sources.
Sounds very promising.
