I have a long-standing gripe about web.config files. They are where you are “officially” supposed to put all your application’s configuration settings, but the framework throws in a whole lot of other so-called configuration settings that are, to all intents and purposes, code. Such as HTTP modules, assembly references, which version of the C# compiler to use, and so on.
This is bad. A well-designed application configuration file will only contain settings that vary from one deployment to the next. Anything that is the same across the majority of deployments should be set in your code either by convention or by default values. Anything that doesn’t change from one deployment to the next is not configuration, but code.
But why not just stop using web.config for your app settings and connection strings altogether? There’s nothing stopping you from writing your own configuration class which pulls in all your application settings and connection strings from a JSON file in the parent directory to your application root, or in the Windows registry, if that’s what you need to do.
Build scripts are another example. What language do you use to write your build scripts? Chances are, you either use NAnt or MSBuild. But both of these are XML-based, unwieldy, tricky to learn and use, and somewhat limited. What’s to stop you using Python or Ruby instead, or even batch files, for instance? They can do everything that NAnt and MSBuild can do and more, they are much simpler to understand and edit, and you can leverage the knowledge involved elsewhere.
Just because the framework provides you with an “official” way of doing something, it doesn’t mean you have to use it. Using a different approach to the officially touted way may sound a bit radical or perhaps even iconoclastic at first, but it makes perfect sense once you think about it. After all, if the accepted wisdom passed down from Redmond is not fit for purpose, blindly sticking with it even though it gets in the way is just cargo cult programming.