Silverlight 2 and ASP.NET MVC showed their heads around the same time and despite all my experience developing with ASP.NET WebForms I jumped in the direction of Silverlight and missed the magic of MVC.  Recently I had the opportunity to work on a little MVC project and really enjoyed the experience.  Since then I have been working on re-writing a personal project, initially I started with MVC 3 but have since moved it up to 4.  I generally use NLog for logging and wanted to integrate it into my MVC project and wanted to use Entity Framework DbContext, Code First and Migrations.  I figured this might be something others would want to do so set about creating a little library to make it easy and fairly painless.  The project lives on github at https://github.com/MikeHanson/NLog.Mvc and includes the following:

• A custom NLog Target that writes log entries to a database using a DbContext instance
• A custom HandleErrorAttribute that logs exceptions via the NLog Target
• A Logger utility class that you can instantiate or inject for other components to implement logging throughout your application.
• I have documented NLog.Mvc within the project wiki at github,, but feel free to ask questions or give me feedback or event request features.  It is working as I need it to in my project, but I haven’t exhaustively tested in other scenarios.

If you practice TDD in any fashion you are going to want to get NCrunch.  It is still in beta, and may become a commercial product at some point but it is pretty stable and for me has become an essential tool.  Imagine being able to just write code (test or functional) without having to pause to run tests.  Imagine making a change to existing code and knowing immediately if it broke any tests without having to manually run the tests.  This continuous development ability is what NCrunch delivers and it has made me significantly more productive in my coding and in a couple of weeks I found this tool as necessary as having a productivity tool like CodeRush or Resharper.

Just spend a few minutes watching the video on the NCrunch home page and if you aren’t immediately hooked on the idea I will be very surprised.

Just finished a contract where we used SpecFlow to define our acceptance tests, and I have been using it on my personal projects for a while.  Anyone using SpecFlow for a while quickly learns that you have to be careful how you organise your step definitions or you can get in a real mess.  It is a great tool but if you tend to just dive in without first finding out the best practice it can be painful.

Recently I discovered SpecSalad.  Duncan Butler has ported CukeSalad over to .NET for us and I for one am glad he did.  Basically SpecSalad takes the pain away by allowing you to define your system as a set of Roles and Tasks.  Steps are replaced by the Task and as each one is a separate class it is much easier to keep track or reuse.  I won’t regurgitate the “how to” as Duncan has some great posts on his blog to get you started.

SpecSalad necessarily constrains the vocabulary you must use, but this has a cool side effect of making it easier for new adopters of BDD to learn the vocabulary.  On my last project the vocabulary was somewhat of a hurdle for the business to getting on board and defining the acceptance tests, for much of it we the developers were defining acceptance tests after the fact, never a good thing in my book.