Configuration Management
There are 4 entries for the tag Configuration Management

If you're writing SOLID code, you're going to be doing a lot of wiring.  Typically, this wiring only changes in response to business change.  Some wiring is going to be static for years.  If you're building a car, you won't suddenly wire the clutch to the CD player, as entertaining as it would be when your brother-in-law tried to drive it. On the other end of this spectrum, there's stuff that changes all the time.  Every machine you use, it needs to change.  This is actual configuration information.  The rest of it can, frankly, be hard wired.  True configuration...

Another thing that we covered at my recent presentation was common use cases of Singletons.  The problem with artificial examples is that you're often presented with objections that the point you're making is restricted to the particular example you've given.  So, instead, let's take a look at some of the most common usages of singleton patterns and explain why you're breaking your code to use them: The Current User I've lost count of the number of times I've seen the current logged-in user accessed through a static method.  It's extremely tempting: there's a phenomenal number of parts of your system...

In the previous post, I dealt with the standard .NET config file.  It would be lovely if all we needed to deal with was appsettings and connection strings.  Sadly, the world is more complex than that.  Now, quite a few of the systems listed below (pretty much all of the XML-based ones) give you the option of including their config in the app.config or in a separate file.  I can't say as I see it makes a blind bit of difference.  Each of them has their own XML schema and I doubt you wish to write a diff tool for...

It's amazing how much engineering time is spent on arguing about the difference in abstraction strategies, followed by someone saying "just copy the files up, but make sure not to touch the config".  This is a recipe for disaster.  There are three common failure scenarios: Someone takes a copy of the live system, runs some tests and accidentally enters the test data into the live system.  I once saw that happen with a stress test.  It wasn't funny.  (In fairness, it's pretty funny in retrospect.) Someone uploads a debug environment, rendering the live system unstable.  (This is mostly...