Self Hosting ASP.NET Web API Service

Windows Communication Foundation (WCF) services provide great flexibility of hosting. We have a number of options to host them. They are Managed Windows Service, Managed Application, Internet Information Services (IIS) and Windows Process Activation Service (WAS). Choosing WAS doesn't seem like an option as this is specially useful for non-HTTP based services, while ASP.NET Web API services are HTTP services.

I thought this would be a good idea to explore the number of different options to host ASP.NET Web API Service and when it would make more sense to choose one of them. In this post, we are going to look at Self Hosting of ASP.Net Web API service using Microsoft.Aspnet.WebApi.SelfHost nuget package. Please remember that this is not a recommended option (any more). For all new services, it is recommended to use Katana, which is an OWIN implementation.

Self Hosting is a generic term used to refer any application which provides its own code (non-declarative) for initializing the hosting environment and maintaining its lifetime[Bustamante, Michele Leroux - CODE Magazine - Jan / Feb 2007]. They can be either of Console, WPF or Windows Forms or a managed Windows Service.



In order to self host ASP.Net Web API Service, we need to install Microsoft.Aspnet.WebApi.SelfHost nuget package. This would install all the required assemblies needed to self host this type of services.



All the required nuget dependencies are also installed with this installation. We can have a look at the installed nuget packages using Package Visualizer. The tool draws a package dependencies graph for all projects in the solution.



Please note the weird dependency for Microsoft.AspNet.WebApi.Core 5.0.0 on Microsoft.AspNet.WebApi.Client 5.0.0. Mark Seemann has also tweeted about this recently. In case you are curious, D in SOLID is not Dependency Injection as I have found many to state that. This is Dependency Inversion Principle. Lostechies.com has a wonderful explanation of the suite of principles for software design.

Microsoft.AspNet.WebApi.Core depends on Microsoft.AspNet.WebApi.Client. Haven't they heard about the Dependency Inversion Principle?

— Mark Seemann (@ploeh) January 7, 2014

Now we just need to provide necessary configuration for hosting the service. Since we have already installed the nuget package, we have all the necessary types required for hosting the service. It also supports attribute routing for self hosting. Let's update the Main method in Program.cs as follows:


Now you might be wondering why in the world I have assigned the full name of InstituteController type to a local variable and haven't even used the variable. Actually I never intended to use the variable. We just need to load the assembly containing the controller type. If the assembly is not loaded, the controller type will not be loaded in the app domain resulting in the failure of resource request. You can find other solutions as well e.g. here someone has recommended a custom assembly resolver. Avoiding the load of assembly would result in a "Resource Not Found" response from the service.



You might have noticed HttpSelfHostConfiguration instead of HttpConfiguration to configure the service. Actually, the type inherits from that. The type is available in System.Web.Http.SelfHost namespace. The assembly is downloaded and referenced as part of the nuget package installation described above. HttpSelfHostServer is also available in the same namespace and assembly.



Now we just need to run and request a resource from a client. Let's run the console application. We can send a request using a browser. Here we are using one of the actions in InstituteController, which results in the following response:



Download