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


Trusting Inputs, Via RESTa Via Nanciacum

All too often, security is treated as an afterthought in our models. I'm as guilty of this as anyone. :) Now that HTTP is becoming the most popular protocol inside the enterprise, sending bad data across the wire becomes much easier. A hidden input field is not all that hidden.

Let's take everyone's second favorite fake business problem: Enrolling Students in Classes. Let's take it further and say we want to develop this as a SaaS product. It'll need to be a multi tenant application. There are lots of independent community colleges (Institutions) out there and we don't want to run a VM or process per Institution.

Obviously, we will need to prevent cross contamination between tenants.


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


Protecting a Self-Hosted Nancy API with Microsoft.Owin.Security.ActiveDirectory

This post is the Nancy version of Vittorio's "Protecting a Self-Hosted API with Microsoft.Owin.Security.ActiveDirectory". Since I'm lazy, I may even be lifting some parts of it verbatim, if you don't mind, Vittorrio ;)

I'm going to skip the intro to Owin etc, if you are reading this, you probably know all about it by now. (Except for you Phillip; Get yout s**t together man!). This tutorial will be using Nancy.MSOwinSecurity that I introduced in the previous post.

What I am going to show you is how you can set up a super simple Nancy HTTP API in a console app and how you can easily secure it with Windows Azure AD with the exact same code you use when programming against IIS Express/full


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