PeanutButter 1.2.0 Release

Short on the heals of the PeanutButter.Utils.Windsor package release, I've updated PeanutButter for all projects and packages to target the .NET framework version 4.5.2. If this doesn't work for you (and it really should), then don't upgrade past 1.1.44.

Why did I do it? .NET 4.5.1 reached EOL on January 16 2016. Nothing should really have changed for any PB consumers -- indeed, I've also cleaned up the nuget package structure to reflect that all packages target .NET 4.5.x and made the change unanimous across the board, thanks to a Visual Studio extension which made it super-easy: Target Framework Migrator Extension (https://visualstudiogallery.msdn.microsoft.com/47bded90-80d8-42af-bc35-4736fdd8cd13)

Anyway, just thought that the few people who read about this stuff should get a heads-up (:

 

New! PeanutButter.Utils.Windsor

 

If you've used dependency injection in .NET at any point in your life, you've probably heard of, or used, Castle.Windsor (http://www.castleproject.org/) in one or more projects. Personally, I've used Autofac, Caliburn Micro's SimpleContainer and the WindsorContainer. They're all quite good -- I guess I've just fallen back on Windsor, most especially in web projects, because it's powerful and quite easy to use.

However, there are some common functions I have to perform with the container, namely:

• Registration of Controller-based classes for dependency injection on my MVC controllers
• Registration of one-to-one service-to-implementations which my code provides (which, let's face it, is probably around 95% of the registration code that we use)

As with other PeanutButter modules, PeanutButter.Utils.Windsor is born out of a desire to stop writing the same (boring) code over and over and spend more time writing new (hopefully interesting) code. As such, please welcome the following extension methods available in PeanutButter.Utils.Windsor, for an IWindsorContainer:

• RegisterAllControllersFrom(params Assembly[] assemblies)
• Searches through the provided assemblies for controllers, matching them by having the System.Web.Mvc.Controller class in their ancestry. Matching is done by class, namespace and assembly name only, so the package doesn't require that you depend on System.Web.Mvc to use it (meaning you can still take advantage of other functionality without pulling in the entire web stack).
• RegisterAllOneToOneResolutionsAsTransientFrom(params Assembly[] assemblies)
• Searches through provided assemblies for all interfaces which are implemented by one non-abstract class and registers the interface as a service resolvable to one transient instance of the non-abstract class. I find that this is what I want about 95% of the time as I'm using DI more for a testing mechanism (and to make dependency chains not my problem at run-time) than anything else.
  This method will also ignore any previously-registered services, so the idea is to run it after any more specific registrations you may have such as services you may want registered as Singleton or PerWebRequest (eg EF database contexts)

Install with nuget, in the console:
install-package PeanutButter.Utils.Windsor

Thoughts? Problems? http://github.com/fluffynuts/PeanutButter is where you can raise issues or make pull requests.

PeanutButter is updated to NUnit 3

NUnit (https://github.com/nunit/nunit) has been updated to version 3 for a little while now, so I thought it best to move PeanutButter forward as the test utilities which use NUnit for assertions and such have required the user to explicitly install NUnit 2.6.4.

In particular, this will affect any new installations or updates to projects using the following:

•  PeanutButter.TestUtils.Generic 
•    Which includes PropertyAssert
• PeanutButter.TestUtils.Entity
• Which includes the helpers around testing database persistence of your entity models

What this means is:

• If you’re not depending on any of these PeanutButter modules, of course nothing changes for you. Though I’d still recommend moving forward to NUnit 3 at some point when you have some time. There are some changes and some things to deal with, so don't rush it.
•  If you have a project which is currently stable and not in active development, don’t bother updating anything unless you really want to stay up-to-date.
•  If you’re going to install-package PeanutButter.<something>, you may find that you’re automatically updated to NUnit 3. Mostly, it’s not a problem and the differences are easy to work around. If you get a PeanutButter package with version 1.1.x instead of 1.0.x, you’re going with NUnit 3. If you don’t want to go this route, install the last 1.0.x version: 1.0.155. You may have to specify an NUnit version to install, ie:
  install-package NUnit –project <your project> -version 2.6.4.
  I used to make my packages not depend on specific versions of anything, but I’ve recently started adding minimum versioning to packages to try to alleviate some of this headache.