Skip to main content

My ideal Bootstrapper...

[Update 29-Apr-12] I've revisited Bootstrapper for a new project and it does register the StartupTasks in the IoC container and resolve them from there too (if you have your IoC extension before your StartupTasks) - this means any dependencies your StartupTask should be resolved. I don't know whether BootStrapper always did this or I was just too lazy to find it out - however with this feature you can pretty much disregard the following post!

[Original Post]
I like the Bootstrapper codeplex project - it's a nice clean approach to setting up your application....however...

I have a specific requirement to satisfy as part of my bootstrap process and I'm not sure if Bootstrapper can solve it. I'll be honest I thought it easier to write this post as I wanted to talk about my ideal Bootstrapper as well as someone hopefully telling me if Bootstrapper can do this or not!.

Lets say I have an IoC container that needs configuring - easily done with Bootstrapper.
I also have some components that need running once to perform some one-time registration. These components require some configuration values from the config file (app/web.config). Bootstrapper provides the IStartupTask interface to allow components to perform this - sweet.

I can just make a call to ConfigurationManager in my IStartupTask component(s) to pick up the relevant appSettings right?

Wrong - this sucks....appSettings suck period as they are insidious dependencies that will break your code left right and centre if you don't know what they are. They have a place in the top level application but in "components" that could be used anywhere in the software stack? No, big no. The only way to understand where they are used is to search the code for ".AppSetting" - but what if they are in an assembly you don't have the code at hand to - well you keep trying to run it until you have smoked out all the settings! Bonkers!

What I want is for the IStartupTask components to take a configuration object in the contructor - this makes it explicit and breaks the horrid appSettings dependency.....but....these constructor parameters will only be injected if the IStartupTasks are resolved through my IoC container (giving it a chance to do the injection).

So my ideal Bootstrapper sequence is this....

Initialise the IoC container
     Perform automatic programmatic registration (find all container registry/setup components and execute them).
     Process Xml config files  (this is where we would register our configuration components).
Scan for all IStartupTask implementations and load them into the Container
ResolveAll components from the container and execute them - this would ensure any ctor dependencies would be injected thus providing our configuration values.

I think I can write an extension method to the Bootstrapper to do this but it would be locked to the IoC container (there is no generic reference to get hold of ANY container used?) - not terrible though.

The key would be to introduce a "common service locator" wrapper over your IoC container in order for Bootstrapper to by able to add all IStartupTasks to the container and then perform a "ResolveAll"

...hmmmm, that's a lot of work just to eradicate appSetting references! Are they so bad if they are used just in the IStartupTask components? - These startup components are unlikely to be used anywhere else in the code/stack....

Your thoughts?


Unknown said…
Im with you. Configuration/settings are a dependency and should be handled as such.

Previously, i used the overly ceremonious IGetXXXSettings pattern so i could have proper constructor injection. I then found FubuCore, which has an IOC friendly way of handling config wiring, so i can use EmailSettings in a constructor, and its behind-the-scenes wiring will grab values from whatever provider is setup.

The ioc registration for FubuCore is a bit long ATM, but i create a StructureMap registry for the sucker and forget about it.

Popular posts from this blog

Walk-Thru: Using Wolfpack to automatically deploy and smoke test your system

First, some history... The advent of NuGet has revolutionised many many aspects of the .Net ecosystem; MyGet, Chocolatey & OctopusDeploy to name a few solutions building upon its success bring even more features to the table.

I also spotted that NuGet could solve a problem I was having with my OSS System Monitoring software Wolfpack; essentially this is a core application framework that uses plugins for extension (Wolfpack Contrib) but how to unify, standardise and streamline how these plugins are made available? NuGet to the rescue again - I wrapped the NuGet infrastructure (I deem NuGet to be so ubiquitous and stable that is has transcended into the software "infrastrucuture" hall of fame) with a new OSS project called Sidewinder. Sidewinder allows me to wrap all my little extension and plugins in NuGet packages and deploy them directly from the Wolfpack application - it even allows me to issue a new version of Wolfpack and have Wolfpack update itself, sweet huh?


Resharper add-in idea - highlight IDisposable vars

[Update 18th July 2013]
@RobGibbens and Greg Hurlman picked up on this - Rob pointed out that there is an FxCop rule that can do this and Greg suggested a Visual Studio extension. I've had a quick look at the Visual Studio options and it looks like an "Editor Extension" is a good fit....hmmm, Project New, click...doh...dammit I really don't have time for this but it looks a fun little diversion! I'll update here if I get anything working.

[Original Post]
Had an interesting idea for a Visual Studio Resharper add-in the other day but don't have the time to implement it so thought I would put it out might already exist (and hopefully someone can point me in the right direction) or someone will build it (Darren Voisey where are you?!).

The idea is very simple really - when you have a variable for an object that implements IDisposable it gets highlighted or a tell-tale is displayed to let you know it should be disposed or should be wrapped in a using sta…

Geckoboard Countdown Widget v2

v2 is here, now with added colours! This time using the RAG Numbers widget to display your date countdown - as you get nearer the date the number will change from green to amber then red.

The new url is:!
Note 1: notice the new /rag/ path and the msg querystring param.
Note 2: the original v1 url still works

To use this on your Geckoboard add a new "Custom Widget/RAG Numbers" widget. By default the number will turn amber at 10 or less days to go and red at 3 or less days to go however you can change these with the querystring (see below).

Required querystring params
date: "yyyy-mm-dd" format, this is the target date to countdown totz: timezone offset in hours from GMT that you are in. Can be negative if you are behind GMT
Optional querystring params
msg: the label that appears next to the number of days (remember to encode spaces as +). The default is "Days Remaining" if you…