If you are using NancyFX, likely at some point you needed to generate a URI of another route in your application.

When I first ran into this problem, I was looking for some type of built-in URI builder, similar to what you would do with ASP.NET MVC’s Url.Action().

Nancy.Linker

Luckily, I found Nancy.Linker by Christian Horsdal.

Simple URI builder for named Nancy routes with optional pass through of query parameters.

It’s really that simple.  What it allows you to do is generate URI’s based on the names given to your routes.

If you are not naming your routes yet, you will need to do so.  This is fairly straightfowrad, and you really only need to do it if you need to use the linker.

Usage

First thing we need to do is acquire the Nancy.Linker package:

PM> Install-Package Nancy.Linker

Now here is an example of an route without a defined name:

To give this route a name, simply supply it as the first argument of the route builder.

In order to build a URI, we must take a dependency on IResourceLinker in our Nancy Module.   I was unable to have IResourceLinker automatically register with my container, so  I’ve registered it in my Boostrapper.

Now we we can generate a URI to a named route.

In my example, I’m going to create another route that is simply going to return the URI of our existing route named “HelloWorldRoute”.

Now if we access http://localhost:5000/findhelloworld via Postman, our results as expected.

Route Parameters

Often your routes will have parameters in which you will need to pass to the linker.  I will modify the above example to include a string route parameter.

Source Code

The source code for this demo is available on Github.

Yesterday it was announced on the ASP.NET Community Standup by Damian Edwards and on Scott Hanselman’s blog that Microsoft has decided to rename ASP.NET 5 (also formerly known as ASP.NET vNext) to ASP.NET Core 1.0.

Reset Major Version Number

As many in the community, I view this rename prior to the RTM as a good thing.  ASP.NET 5 was a very confusing name as it is a completely new version of ASP.NET.  I welcome the reset to 1.0 as it gives a better description that this is indeed a rewrite and ground up work.

Also, frameworks such as Entity Framework had also had an identity crisis as they also were just incrementing the major version number, even though they are completely new as well.  Because of this, Entity Framwork 7 is now being renamed to Entity Framework Core 1.0

Core

I’m still unsure about how I feel about adding the word “Core” to the framework name.  My main concerns are:

Google Juice

How does this affect searching and Google results?  Searching and when creating content that will be indexed must include the word “Core” and possibly the version number.

Version number may not be an issue as there won’t likely be an overlap in somewhat current/useful version numbers.  Eg, Entity Framework 5 vs Entity Framework Core 5.

Perception

This is a rewrite.  As Steve Smith blogged with the history and meaning behind ASP and ASP.NET, it may not seem valid anymore to call it Active Server Pages.

I do think the perception of Microsoft and it’s association to .NET is changing (for the better?) to developers not currently using .NET.  However, I do believe there is a stigma associated ASP.NET in these other communities.

I’m all about welcoming more developers, junior and seasoned, to the .NET ecosystem.  I would think ditching the ASP.NET name altogether might of helped in that direction more.

I am also aware of how much effort has been put into the ASP.NET brand, and you aren’t going to just throw that away, even if it may not have the best perception.

Overall

I’m happy with this decision.  Would I of preferred “Some Short Googleable Name” 1.0? I think so.  But ASP.NET Core 1.0 is much better than ASP.NET 5.

I do think there will still be some lingering confusion since the name ASP.NET 5 has been living for a bit, but with due time it will be water under the bridge.

 

Last week I decided to start migrating one of my existing ASP.NET application that uses NancyFX over to ASP.NET Core.  The process is actually pretty straight forward if you are familiar with OWIN.

OWIN

OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules for .NET web development, and, by being an open standard, stimulate the open source ecosystem of .NET web development tools.

To clarify and reword slightly, OWIN is a open source specification that is not defined by Microsoft and is not an actual implementation.

ASP.NET Core supports OWIN and defines middleware to be used in a  request pipeline with the Microsoft.AspNet.Owin package.

ASP.NET Core NancyFX Demo

All of the source code for this demo is available on GitHub.

The first thing we are going to do for this demo is add the appropriate nuget packages.

Note: At the time of this post, ASP.NET Core is curently at RC1, which is still a pre-release and therfore you will need to include the “-Pre” option when installing any pre-release packages.

PM> Install-Package Microsoft.AspNet.Owin -Pre

PM> Install-Package Nancy

PM> Install-Package Nancy.Owin

Now in our Configuration method of our Startup class, there is a new extension method of UseOwin provided by the Microsoft.Asp.Net.Owin package, which allows us to include additional OWIN compatible middleware to our ASP.NET Core pipeline.

The Nancy.Owin package also provides an extension method UseNancy that we can use inside our UseOwn method.

For the demo, I’ve created a simple Nancy Module.  Since Nancy will find it automatically (which is really nice) there is no registration needed.

Nancy does not support targeting .NET Core however does support Mono.  You will have to remove the “dnxcore50” from frameworks section of the project.json

At this point, you are ready to run the demo.  Your application should be hosted on port 5000.  Calling http://localhost:5000/nancy/demo using Postman produces the expected output.

Owin Performance

The ASP.NET Core documentation notes that you should not use multiple calls to UseOwin.  Rather, insert all of your OWIN middleware grouped together within one UseOwin call.

Source Code

The source code for this demo is available on Github.

ASP.NET Core Series

• The Basics