Hosting WebAPI using OWIN in a windows service

Question

I\'ve self-hosted Web API using OWIN (inside a windows service). From what I understand, this is enough to make HTTP requests come to the windows service. I\'m able to hit t

Answer 1

There are 2 things that will prevent you from using anything different from "localhost" in Owin service:

1. The app needs to run as admin in order to open a port with a different hostname as "localhost". You can fix this by either run the app with admin privileges or add an exception for a given port using: netsh http add urlacl url=http://*:9000/ user=<your user>
2. The windows firewall may block traffic from other computers. In my case the firewall was not blocking local traffic (I could get to http://localhost:9000 or http://127.0.0.1:9000 or http://192.168.1.193:9000 - which was my local IP address from the same computer, but needed to add a port exception to the firewall to allow getting to this service from another computer)

Answer 2

What worked for me in the end was this value:

StartOptions options = new StartOptions();
options.Urls.Add("http://*:9095");

using (WebApp.Start<Program>(options))
{
    ...
}

Be aware that after adding this, you can only run the application in Visual Studio using Admin mode and the release version of the app needs also to be run in Admin mode.

Answer 3

I was facing a similar issue. Below solution worked for me.

StartOptions options = new StartOptions();
options.Urls.Add("http://localhost:9095");
options.Urls.Add("http://127.0.0.1:9095");
options.Urls.Add(string.Format("http://{0}:9095", Environment.MachineName));

using (WebApp.Start<Program>(options))
{
    ...
}

Answer 4

Similar issue. I had written a ServiceStack Service and hosted it inside a Windows service using an AppSelfHostBase implementation. Note: This was written as a Net Core application that compiles as a console application but, through the magic of PeterKottas.DotNetCore.WindowsService (available through NuGet) can be installed as a Windows Service.

I set the baseAddress to http://*.8088/ and passed it to my AppSelfHostBase implementation, but I could only reach the service from the same machine it was installed on and no other, as ascertained by trying to open the metadata page (http://[machine]:8088/api/metadata) in a browser. The solution was to add my console application .exe file to the list of allowed apps in Windows Firewall on the server where it was installed. Just go to the Firewall "allowed app" dialog in control panel on the server, click the "Allow another app..." button, and navigate to the Windows Service executable:

Answer 5

This is actually a simple oversight I also tripped on: If you only listen to requests on localhost, 127.0.0.1, etc -- no one will ever see it because only YOU (self) understands you as that target. On my machine I am localhost, if I req your IP on any port, that service would see get http://your_ip:80, not localhost. All you have to do is serve on "http://*:{0}", and that way you can onStart() pass the port.

Answer 6

Your machine's firewall could be blocking the incoming requests. You could do:

You could Run wf.msc command to open up Windows Firewall with Advanced Security and add a new Inbound Rule for TCP port 80.

(You should notice couple of inbound rules starting with World Wide Web Services.... These are for IIS. I am not sure if enabling these rules would be enough to even allow your windows service to receive the requests...you can try and see if this works otherwise as suggested before, you can create a new inbound rule..)

Update:
Based on your comment, it could be that because of your Url registrations you are unable to hit the service. Following are some examples of registering multiple urls with HttpListener.

StartOptions options = new StartOptions();
options.Urls.Add("http://localhost:9095");
options.Urls.Add("http://127.0.0.1:9095");
options.Urls.Add(string.Format("http://{0}:9095", Environment.MachineName));

using (WebApp.Start<Program>(options))
{

You can read more about the url registration in the following links:
http://technet.microsoft.com/en-us/library/bb630429.aspx
http://technet.microsoft.com/en-us/library/bb677364.aspx