Self Host ASP.NET Web Api as a Windows Service

In my previous blog I demonstrated how to Self Host ASP.NET Web API, which was a very basic console application leveraging Owin and Katana.

The next step in this series is how to turn your console application into a Windows service.

If you have any questions, please follow me on Twitter.

Video

If you prefer a video tutorial, here is one I published to YouTube outlining a similar example as on this post.

Windows Service Template

The typical way to create a Windows Service is by using the Windows Service template when creating a new project within Visual Studio.

The template will create a Program.cs calling ServiceBase.Run() in the Main() method.

SelfHostServiceBase is the code that will extend ServiceBase.   You would have to implement OnStart() and OnStop()

That’s simplest possible implementation.  Now when you start debugging, you are treated with this wonderful message.

service

What this means is you must build your Windows service, start it, then attach the debugger to the process.

Doesn’t sound like a fun way to debug does it?

Topself

TopshelfThere is a great open source project called Topshelf which allows you to create a windows service which is much easier to debug.

Topshelf is a framework for hosting services written using the .NET framework. The creation of services is simplified, allowing developers to create a simple console application that can be installed as a service using Topshelf. The reason for this is simple: It is far easier to debug a console application than a service. And once the application is tested and ready for production, Topshelf makes it easy to install the application as a service.

First thing is to install Topshelf into your project via nuget.

Install-Package Topshelf

Next we need a tiny bit of code to configure our service with topshelf.

We tell topself which class will contain our service (TopselfService) as well as which method to call when the service starts and stops.

Also, you can define which user the service should run as, as well as the name, display name and description.

Now when you debug the application, it will run just like a Console application, in which you can add breakpoints and debug.

Self Host ASP.NET Web API

To verify my web api application is responding, here is the result from my Postman call

Postman

 

2-hour Video Course for $30 USD

Sign up for more info!

* indicates required




 

Source Code

GithubThe source code for this demo is available on Github.

Next…

Next up I’ll continue adding to the demo by serving static assets from your self host application.

How to Self Host ASP.NET Web Api

OWINOver the past several months, I’ve talked to a few people that were completely unaware that you could self host ASP.NET Web Api application without the need for IIS.

Anyone who has worked with IIS knows that sometimes it can feel a bit heavy.  Especially if you not using any other features other than serving static content or executing your ASP.NET Web Api.

There are a couple important aspects to cover first which are what makes self hosting possible.

If you have any questions, please follow me on Twitter.

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.

Katana

Katana is an open source project by the Microsoft Open Technologies.  It’s a set of components for building and hosting OWIN-based web applications that follows the OWIN  specification.

I’m not entirely sure what the status is of OWIN/Katana within ASP.NET 5 (vNext), however I would like to think the separation between server, host, middleware, and application will continue.

Video Tutorial

If you prefer to follow along with a video tutorial, take a look at the video below.

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 create a Console Application and add the Owin SelfHost and WebAPI Owin Selfhost nuget packages

PM> Install-Package Microsoft.Owin.SelfHost

PM> Install-Package Microsoft.AspNet.WebApi.OwinSelfHost

Next, we will create a Startup class that will contain the HttpConfiguration similar to how you configure Web Api currently.   The startup class is the implementation of the OWIN specification that our OWIN Self Host implementation will use.  The Startup class must provide a public Configuration() method with the signature void.

Next, we will create a simple ApiController.

Last step is to add the web server implementation to out Program.cs Main() method.  This is done by simply calling out Katana implementation of WebApp.Start and passing our Startup class name as a type argument along with the host/port binding details as the first parameter argument.

That’s it!  Now when I make a call from Postman to http://localhost:8080/api/demo, here are the results:

selfhost

 

2-hour Video Course for $30 USD

Sign up for more info!

* indicates required




 

Source Code

GithubThe source code for this demo is available on Github.

More

Event Stream as a Message Queue

I was recently having a discussion around a system being built using Microsoft Azure.  Some concepts being discussed for this system where CQRS, Event Sourcing and Message Queue.

The diagram below is fairly typical when discussing CQRS and Event Sourcing.

Message Queue

One of the first things that stood out to me was the use of the Message Queue and Azure Service Bus.

For this blog post, I want to focus on the Service bus, which is used for publish-subscribe pattern.  The domain will emit events that are stored to the event stream and then will be published to the Service Bus.  Subscribers, such as Projections or other Bounded Contexts will process these events.

Forgotten Option

There is nothing wrong with using a service bus to publish domain events.

However, one option which is seemingly always forgotten to developers that are new to CQRS and Event Sourcing:

Your event stream can be used as a message queue

Other bounded contexts or projections can query/poll your event storage to retrieve new events that have been persisted.

At regular intervals, the event consumer could poll your event storage requesting any number of new events based on the last event it processed.

The consumer would be required to keep track of the last event it processed in order.  This provides some benefits as it may not be a process that is required to be continuously running.

You may be thinking: Polling? Really?

If you rolled your own event storage, I could understand how this might be problematic and would likely be easier to use a service bus.  Or you may want your event consumers to process the event as soon as possible.  Your implementation of how to handle this is dependant on how you are currently storing your events.

But the point still remains: Your event stream is a message queue.

As always, context is king.  Requirements and many other factors will play into how you want to handle messaging.

It is another option that may fit a scenario that you run into.

Event Store

Event Store

If you are just thinking about getting into Event Sourcing, I would highly recommend looking at Event Store by Greg Young as your event storage.

Event Store supports multiple types of Subscriptions including Persistent Subscriptions for the Competing Consumers messaging pattern.