James Simmonds

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

[ 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

[Update 19th Apr 2012]  - mission complete!...v2.4.0 of Wolfpack has been released and this includes a new set of plugins that can automatically download a NuGet package then execute a deployment tool (eg: DropkicK, MSBuild.exe) - it can even run NUnit tests (via the console runner). Wolfpack v2.4.0 Wolfpack.Contrib.Deployment [Original Post] Another day, another project and deployment raises its head... Thinking that this problem must have been cracked by now I had a look around the .Net landscape and found two interesting solutions. Octopus Deploy - a .Net convention based deployment system using NuGet packages, loosely based on AppHarbour's approach. DropkicK (aka DK) - another awesome initiative from Dru Sellers et al. I like the simplicity of Octopus but also like DK's  fluent code based deployment. Hmmm, this has got me thinking - Wolfpack could easily be adapted to be used as a deployment agent. Wolfpack can already monitor a NuGet feed for new pack

I'm getting excited about the next release of Wolfpack (v2.3). It's going to be the first application  that uses Sidewinder  (unless someone beats me to it with my own framework!). I'd been discussing updates and NuGet with a few people and wondered how it could be applied to Wolfpack - its plugin architecture makes it a perfect candidate for being able to download or upgrade plugins plus I also wanted to explore a better way of upgrading the entire install - make this as painless as possible. Taking inspiration from the NuGet.exe commandline app that self updates I had a look at the code and took the plunge and created Sidewinder. I'll let you investigate Sidewinder yourself (if it sounds interesting) but wanted to share what this will mean when it lands in the next version of Wolfpack and how I plan to use it. Wolfpack is a pluggable, modular system - a number of contrib projects have sprung up and a few dedicated individuals have invested time and effort into a

Hurrah! Version 2.1 of Wolfpack (formally MonitorWang) is released! This release is all about " Build Analytics " - a new set of plugins allow you to monitor the state of a TeamCity build configuration and then once this is complete it can extract stats from any* build tool run as part of it. * When I say any I mean it supports NCover, SpecFlow, StoryQ reports but as usual with Wolfpack it is easy to create your own parsers to extract from any tool you might use, eg: NDepends, FxCop. It is also simple to extend it to cover other build systems like TFS, CruiseControl. The final piece of the puzzle of to visualise this information and the Wolfpack Geckoboard Data Service does a great job of this - it allows you to display these stats directly in your Geckoboard .

I've observed an interesting trend from my download statistics on my main open source project, MonitorWang ...that downloads often increase on a Friday. What can we infer from this? Developers have some down time to look at "other" stuff on Friday? Interesting to know how official this is or just people getting bored with the humdrum stuff and looking for something interesting to do at the end of the week? MonitorWang's official birthday is 8th August when I first uploaded it to codeplex however it was in conception & development way before that so it's almost a year old. It's racked up over 1000 downloads and I've got some big plans for it to be revealed shortly. More importantly I'm starting to get feedback and success stories of it in use which is the icing on the cake - 1000 downloads means nothing if it's not of value to someone! Thanks to everyone that has helped shape & contribute to it, in particular Rob Gibbens and David St