One Nancy blog to aggregate them all!

I have been wanting to create a Nancy blog for a very long time. My initial idea was to create a blog that used static files and posts in markdown format (like Sandra.Snow, which is built using Nancy, or Jekyll) and have people submit pull-requests if they wanted to share content.

A lack of time got the better of me and I never got any further than creating an empty repository. The idea never vanished and it has been something that we (the core contributors of Nancy) recently started talking about again.

During our meeting it was brought up again and we thought it was a great idea and that we should act on it. The next day Jonathan Channon shared his first spike of the blog that, behind


Our sights are set on releasing v1

Over the years, we have often gotten the question on when we will be releasing v1 of Nancy. While it has never been important to us, many have been claiming that this is something that is important for enterprise adoption.

I still remember when we went from 0.9.0 to 0.10.0 and many thought we were crazy. Apparently 1.0.0 is the obvious next version after 0.9.0, right? With the current release being 0.23.0, you can perhaps tell that we did not agree.

Of course, it is my personal belief, that changing the version number to v1, is just an artificial sense of security. Nothing else is going to change in terms of support or promises (well almost, more about versioning further below).


Streamlining our community presence

There as several ways that our community are able to communicate with us and each other

However, we want to make a small adjustment to that. If you are using our Google group, then you should definitly keep on reading.


The governance of Nancy has been expanded

On the Nov 20, Nancy will be celebrating her 4th birthday. That is quite an achivement for any open-source project, even more so for a project in the .NET ecosystem.

During these four years a lot has happened, but apart from when Steven was added as a core contributor back on Mar 31, 2011, no one else has been granted permission to commit code to the main repository.

That is, until now.


Nancy, ASP.Net vNext, VS2014 & Azure

By now we know of Microsoft's plans for the next version of ASP.Net and they've turned it on its head and from the looks of it, its goooooood!

Here is a blog post from Scott Hanselman introducing ASP.Net vNext. There are introductory and deep dive videos available for your perusal which are also well worth a watch.

The TL;DR is ASP.Net vNext will take heavy influence from Node.js by using Owin to wire up all the app dependencies and middleware. It will also remove *.csproj files and use a project.json file similar to Node's package.json and use NuGet to reference the application's dependencies. It also takes inspiration from Node and Nancy's approach requiring you to opt-in to


Introducing Owin.StatelessAuth with Nancy/Angular demo

If you're writing an API, current thinking is to provide a token in the Authorization header for your app to validate when the request comes in. I have used the Nancy.Authentication.Stateless package in the past for my APIs and even have a demo of it here if you're interested (there are more Nancy demos at This is a great package and does a great job but what if one day you want to use SignalR v2 that uses OWIN and you want to validate not just requests to your Nancy app but also the SignalR requests? You're going to need to validate requests as they come in before they get to SignalR or Nancy.

For those of you who are not quite up to date or unsure what OWIN


Bubbling exceptions in Nancy up the owin pipeline

In the application I am building I have a requirement to do common exception handling within my OWIN pipeline via custom middleware:

private class CustomExceptionMiddleware : OwinMiddleware
    public CustomExceptionMiddleware(OwinMiddleware next) : base(next)

    public override async Task Invoke(IOwinContext context)
            await Next.Invoke(context);
        catch(Exception ex)
            // Custom stuff here


Community maintained Nancy F# templates for Visual Studio

Not too long ago, I posted about the Visual Studio templates for Nancy and how we had taken the (tough) decision to only maintain C# templates outselves. Not because we do not see value in supporting other languages, but solely because of the shear amount of work that is required to maintain a single template.

Maintaining 9 templates (as we do with out C# templates) is a time consuming process, and the time required to support additional templates scales linear to the amount of templates we add.

We reached out the authors of the VB.NET templates and F# templates, as well as our community, and ask them to maintain the templates themselves. I didn't take long for the F# community to step up


On the Nancy templates for Visual Studio

A while back we introduced Nancy templates for Visual Studio, which gave you the ability to create a new Nancy project that has Nancy added out-of-the-box. This meant no more creating an empty ASP.NET web application, removing all those pesky project references and installing the Nancy nugets, just to get up and running.

Unfortunately we have not been able to update these template with every new release of Nancy, which means you have had to update the Nancy Nugets to make sure you where using the latest build.

Believe me when I tell you that this has not been out of laziness, but rather the instinct to survive, but hopefully we've taken a couple of important decisions to remedy this in


Supporting Single Sign On In Your Nancy Applications

In enterprise application the requirement for single sign on is common: Users are already authenticated against the domain controller - they don't want to jump through another authentication hoop to get access to your particular application. Setting this up in ASP.NET using WIF is some pretty easy web.config gymnastics and described elsewhere. The result of this setup is that the current principal on authenticated requests is a ClaimsPrincipal identifying the user in terms of the claims setup for him/her in the identity provided (e.g. your organizations Active Directory).
Below I show how to integrate the WIF authentication setup with your Nancy application - It doesn't take much, but lets