I've been spending more and more time thinking about how we over-engineer solutions and even libraries.  Currently my feeling is that NuGet and OpenWrap are only going to make this problem worse and not better.  The basic problem with buy versus build is that it's posing the wrong choice.  Of course buy is cheaper than build.  But it's like trying to chose between sparkling and still: the correct answer is tap. A number of years ago I built a system that used Binsor for configuration.  Here were the benefits (to me): Concise syntax ...

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...

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...

I thought I'd write a bit about how I understand the philosophy of IoC containers.  I realize I'm actually building up to something that I started talking about a while ago.  I'm probably not saying anything that Martin Fowler didn't say before, but I have my own slant on it.  To start off with, I'd like to just review what we actually mean by various terms: Inversion of Control (IoC) is a general name for the pattern where an object isn't responsible for managing the lifecycle of the services it uses.  The simplest way to implement this (in .NET)...

If, like me, you're using Binsor for configuration, and using the include file mechanism to implement environmental deltas, you're going to need to refer to the initial file using an absolute path.  The reason for this is, if you don't, a relative path name within the Binsor script uses the current working directory.  Just to be annoying, this means that all of your code works until the moment you deploy it, and then your service fails to start (this bears no resemblance to a real issue, I can assure you...) Anyway, here's the code you need: private static...