Update PeanutButter - now with less pain!

 (and possibly more fibre)

Necessity Laziness is the mother of all invention. It's the reason PeanutButter (https://github.com/fluffynuts/PeanutButter) even exists and is on Nuget. But as PeanutButter has expanded in its modular fashion, one thing has bugged me: updating.

When I change one Nuget library, I update all Nuget packages to avoid any confusion about which version of what plays nicely with the other - to the point where I've even made each package which depends on another PeanutButter package depend on the same version as itself. I wanted an easy way to update all PeanutButter packages since I release quite often - indeed, pretty-much whenever I add any functionality.

An approach to this problem might be running update-package from the package manager console. Whilst I'm a fan of keeping libraries up to date, sometimes you can get unexpected consequences from this action such as breaking a site depending on an older version of ASP.NET MVC. I have no control over those other packages -- but I do control PeanutButter, so what I need is something more like update-peanutbutter.

And now I (and anyone else using PeanutButter) have it.

Thanks to an excellent tutorial by Phil Haack on his blog You've Been Haacked, I've added the command via a module loaded from the PeanutButter.Utils Nuget package init script. PeanutButter.Utils is one of the "lowest-down" packages, so chances are very good that if you're using any of the others, you're using PeanutButter.Utils. The change is available from version 1.2.15 and the easiest way to take advantage of it would be to update one of your projects to use the latest PeanutButter.Utils and then use update-peanutbutter from the package manager console to update all the other projects in your solution.

Happy hacking (:

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.

Razor views and publishing woes

If you've done any ASP.NET MVC work, especially in VS2015, you may have encountered this:

•  You’re devving away on a controller and return View(withSomeNiftyModel).
• You alt-enter or alt-. to get VS to create the view
• You make some amazing html view. It has tags and content and everything!
• You test the view using an F5 or Ctrl-F5 and it’s doing what you want and looking how you want (though your designer, who may or may not be named Jess, probably has sterner words about how it looks)
• Some time later, you build a deployment package and upload to the client.
• If the internet gnomes are with you, soon you will deploy at the client. If not, you’ll wait… and then deploy at the client
• And then you get the dreaded “view not found error page”:

Well, you don’t have to continue with this sad existence. You could add this snippet to your web project’s .csproj file:

  <Target Name="EnsureContentOnViews" BeforeTargets="BeforeBuild">

    <ItemGroup>

      <Filtered Include="@(None)" Condition="'%(Extension)' == '.cshtml'" />

    </ItemGroup>

    <Error Condition="'@(Filtered)'!=''" Code="CSHTML" File="$(MSBuildProjectDirectory)\%(Filtered.Identity)" Text="View is not set to [BuildAction:Content]" />

  </Target>

(Place it after the ItemGroup which contains your views, if you’re looking for a spot to put it)

And then, voila! Your project doesn’t build unless all views are set to build action content:

Kudos to the solution here: http://stackoverflow.com/questions/27954267/make-sure-all-cshtml-files-are-set-to-be-content-for-build-action (though I’ve upgraded from a warning to an error, because, well, it should be).

Please welcome PeanutButter 1.0.118!

 (if you don't know what PeanutButter is -- apart from a yummy spread and a rather silly name for an open-source project -- have a gander here: http://davydm.blogspot.co.za/2014/06/introducing.html)

What's new:

• Updates to DatabaseHelpers:
• Fluent syntax for conditions (.And() and .Or() extension methods)
• EqualityOperators changes
• Like_ is deprecated (but still functions). It is replaced by Contains, with the same functionality
• Like is new: does not insert any wildcards -- that's up to you! (also, finally, has a reasonable name, now that I know how to use keywords as identifiers in VB.NET. Yes, the DBHelpers are written in VB.NET. Get over it.)
• StartsWith: does what it says on the tin
• EndsWith: also does what it says on the tin
• Added ConcatenatedField for when you want some composite result from a few fields
• Updated CalculatedField: All *Fields now implement IField, so all of the existing funcationality which SelectFields could give you can also be found for the others (conditions, etc)
• Enumerable convenience functions
• And() -- like Union() but produces an Array
• eg new[] { 1, 2 }.And(3) is equivalent to new[] { 1,2,3}
• ButNot() -- like Except(), but produces an Array
• RandomGenerators:
• RandomValueGen.GetRandomCollection
• Takes a factory function and optionally min/max number of items
• eg to get a random-sized IEnumerable<int> of random ints, do:
  RandomValueGen.GetRandomCollection(() => RandomValueGen.GetRandomInt())
• RandomValueGen.GetRandomSelectionFrom
• picks some random items from another collection
• ExpressionHelper: 
• GetMemberPathFor:
  use to get full property paths from lambdas, eg
  ExpressionHelper.GetMemberPathFor<Foo>(fooItem => fooItem.SomeProperty.SomeValue)
  gets you
  "SomeProperty.SomeValue"
  Useful for testing or somewhere where you need to get to properties dynamically
• GetPropertyTypeFor:
  Similar usage to GetMemberPathFor, but returns the property type
• Of course, there are some bugfixes
• And probably other stuff I forgot... It's been a while since I tooted on the PeanutButter horn.

 Like other PeanutButter bits and pieces, these have been born out of a desire for convenience, cleaner code and/or getting the compiler to check stuff before hitting the runtime. I hope they benefit others -- I know that I use a little PB every day (:

As always, usage, source availability and distribution remain totally free.

Introducing... Splunk4Net!

 

One of the cool parts of working for Chillisoft is that we have time set aside by the company for learning and experimenting. We call those times "Intentional Learning" and "Deliberate Practice". Think "Google 20% time", but with a little more focus.

The last round has been focused on tinkering on projects of interest to people working at the company. One of my colleagues is working on using Unity to build a virtual world interface to a part of an existing product. Some others have worked on a Neo4J .NET connector. There are some cool things which emerge from these processes!

I had recently dealt with Splunk, a remote hosting for logging which not only provides a rich query language to deal with the collected data, but also provides graphing mechanisms for making your data come alive visually. They have many different pricing structures, starting at a free version which is probably enough to cover the needs of quite a few projects and teams, right up to enterprise editions which cope with high volumes of data and provide rich security features.

A lot of the .net world has already dealt with the great log4net library: an open-source logging framework which supports writing to a diverse plethora of targets, such as log files (with rotation even!), Windows Event Log and many, many more.

So log4net is cool, Splunk is cool -- how about making it easy to log to Splunk using known log4net skills?

Well, now you can, with Splunk4Net, which is available via nuget. Thanks to the community-oriented thinking at Chillisoft, this library is not only free as in beer, but you have full access to the source -- you can build it, you can change it, you can redistribute it.

I hope this provides some value to people looking to log to an external service, especially to be able to harvest valuable information from that logging. You could use this to keep on top of error conditions in your client code or websites. You could use this to gather metrics about application usage to guide further development. You could just use this as a diagnostic tool to figure out why client apps are falling over. How you use it is up to you -- feel free (: