As you probably know, the ASP.NET team is publishing the latest ASP.NET Web API on a nightly MyGet feed, and you can grab them from there and play with the latest stuff without having to deal with all the hassle related to building from the source.

The same applies to Katana, a Microsoft generic Owin host, which also has its own MyGet nightly feed.

Let’s glimpse into the near future and have a look at putting the latest Katana bits to play with ASP.NET Web API and other frameworks.

Intro to Owin and Katana

This post is not intended to be a basic introduction into Owin or Katana; there are plenty other good resources on the web about that.

Paul Glavich has recently written a great post about getting started with Owin and Katana. Yesterday, Tugberk Ugurlu followed that with another very cool introductory post.

Let’s also throw in Nancy there, to illustrate how different frameworks can play together nicely with Owin:

XHTML

1

2

<package id="Nancy"version="0.17.1"targetFramework="net45" />

<package id="Nancy.Owin"version="0.17.1"targetFramework="net45" />

Multi-hosting self host

One of the most exciting features Owin enables, is the multi-hosting self host mode. Most of the .NET web frameworks allow you to perform some sort of self hosting (to avoid IIS). This is normally based on HttpListener and normally requires a dedicated port (a.k.a “port cannibalizing”).

With Owin, these frameworks delegate the ownership of the HTTP listener to the underlying Owin host, in this case, Katana.

Owin supports multi hosting through host.Addresses configuration key:

C#

1

2

3

4

5

6

7

8

varaddresses=newList<IDictionary<string,object>>();

addresses.Add(newDictionary<string,object>

{

{"scheme",scheme},

{"host",host},

{"port",port},

{"path",path}

});

Pretty much all Owin configuration is done through such lists of dictionarieis, and of course working with dictionaries is hardly desirable for everyday development tasks, therefore each of the frameworks provides an Owin adapter – such as the ones we used in our packages.config:

– Microsoft.AspNet.SignalR.Owin

– Microsoft.AspNet.WebApi.OwinHost

– Nancy.Owin

The also normally provide OwinExtensions methods allowing for easy registration of a given framework against the Owin host.

In this case, we have created a Web API config, and instructed Owin IAppBuilder to use it. We also registered SignalR hubs and Nancy against the same IAppBuilder – which will sit on port 999.

Note, this line

C#

1

builder.Properties["host.AppName"]="filip app";

shouldn’t be requried, but I ran into some issues that where it wasn’t set, SignalR was throwing null reference, but I’m guessing this will be fixed sooner or later.

With such set we now have:

Nancy at http://localhost:999/

Web API at http://localhost:999/api

Signalr at http://localhost:999/signalr

Let’s throw in some basic classes related to these frameworks – a SignalR hub, Web API controller and a Nancy module:

C#

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

[HubName("hellohub")]

publicclassMyHub:Hub

{

publicvoidSend(stringmessage)

{

Clients.All.addMessage(message);

}

}

publicclassIndexModule:NancyModule

{

publicIndexModule()

{

Get["/"]=x=>

{

return"Hello Nancy!";

};

}

}

publicclassTestController:ApiController

{

publicstringGet()

{

return"Hello Web Api";

}

}

We can now run our solution and voila! Everything running side by side, in perfect harmony!

And SignalR:

Owin support is coming in the future release of Web API, and soon we will all be doing ASP.NET development with server and application being completely decoupled through the use of Owin! The potential here is amazing!

Just to clarify my understanding, these are all registered within the same application, correct? Thus they are able to share the same port and map the request based on URL. You could still have conflicts between two different self hosted applications that are trying to leverage the same port, correct?