Web Services

Web service inside a Windows service without IIS

Update: If you have any questions about this article or any other web-services related queries then please ask! I see alot of traffic coming from Google about web-services and related issues/problems which this text doesn’t cover but I can probably help with! Leave a comment and I will respond quickly – if I don’t have the answers then I bet I know someone that does.

Skip to the Ramble End section to get into the guts of the article… the first part is just me talking too much as usual.

I’ve decided I need to get out more (it was either me or my shrink – I cant remember. Ed.); see the sights, expand my horizons, meet new media dissemination platforms.

I find myself writing and documenting code for my team mates at Objectify – tidbits of information here and there, how-to’s, faq, code snippets, my secret pasta recipe etc. – all usually transmitted in email form, with the occasional Word or PDF doc if they are lucky. If they are really lucky I may enter it into our internal FAQ system… for a fee.

Why not blog about some stuff too? See just for interests sake if anybody is interested in anything I say.

I thought I would start off nice and easy – ease into the Blogoshere nice and slowly (note to self – blog about hating the word “Blogoshere”… oh someone already did, damn). So I’m opening up the innings with a little ditty about hosting web services inside a windows service without the need for IIS. I wrote this doco about a year and a half ago, so its basically a translation of some old stuff… Sure its nothing too technical, its not ahead of the curve so to speak, and its probably been done a thousand times but we all gotta start somewhere. If we get time we may even throw in some SOAP headers and AES encryption for good measure – nothing like a pre-shared key to brighten your day. Okay well maybe in the next entry.

I first came across the need for a web service inside a windows service when thinking about ways to decentralise the Objectify CMS debugging system. Basically the debugging system goes way back to the days of the first CMS, all written in VB6 mind you, and uses mail slots to transfer messages from an array of COM objects to the debugger output application. Problem was that clients (and internal testers etc.) had to log into the server and run the application to see the messages. Now I know what you are going to say – you can pipe mailslot data between machines, problem solved… but I wanted to try something new, so web services it was.

Ramble End

We will end up with a simple web service windows service (WSWS?) with an interface to query which will do some simple processing for posterity’s sake and return a message to the client.
Firstly, you are going to need Web Services Enhancements 3.0 from Microsoft. Hop along to http://msdn2.microsoft.com/en-gb/webservices/Aa740663.aspx and grab a copy – make sure you install the developer option (the Visual Studio developer option if you are using VS). It will distribute itself with your app when you build the installer (if you choose to) so no need to install the MSI on your target machine.

Start your new project by creating a class library. I called mine something original – Web Service inside a Windows Service. This is where we will be placing the bulk of the code. Create a new public class called HostWebService.

Add in references to Microsoft.Web.Services3 and System.Web.Services.

Begin your code by adding the following namespace includes:

using Microsoft.Web.Services3;
using Microsoft.Web.Services3.Addressing;
using Microsoft.Web.Services3.Messaging;
using System.Net;

Okay so we are ready to go. Too easy. In the constructor we need to do some things to start our little web service listener. First, we need to know the local machine’s DNS address, and use this address to create a URI for our new Web Service (i.e. the address that will be used in the client application to query the service).

 string hostName = Dns.GetHostName();
 IPHostEntry ipEntry = Dns.GetHostEntry(hostName);
 Uri address = new Uri("soap.tcp://" + ipEntry.AddressList[0].ToString() + "/MyLittleWebService");

By the way, did I mention that if you know a better way to do any of this the please feel free to comment – i.e. is that the best way to get the IP of the local machine?

You can see above that the Uri address=xxxxx line is where you set the actual URI of the service, you can change the last part from MyLittleWebService to something more fitting if you like.

Now we need to create the actual web service code… It’s basically the same code that is generated by Visual Studio when you create a web service (the code behind in the Service.asmx file). Create a new class called WebServiceCode.cs and paste in the following:

using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;

[WebService(Namespace = "http://myURI/MyLittleWebService")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class WebServiceCode : System.Web.Services.WebService
    public WebServiceCode()

    public string GetMessages(string guid)
        return "At the third stroke the time will be " + DateTime.Now.ToString();


Nothing too tricky there, stock standard web service stuff. Next we go back into the HostWebService class and add the following just below the URI stuff:

 SoapReceivers.Add(new EndpointReference(address), typeof(WebServiceCode));

And we’re done… almost. Well we’re done to the point that if you run that code (from a test app or something) then you will have a windows app that is hosting a web service. Thats great, but how do you query said service?

Accessing the new service

Before we can access the new web service we need to add it as a Web Reference to our project. Normally this is nice and easy, just right click and add a Web Reference in Visual Studio and let WDSL do the work. Problem is this new web service isn’t published anywhere yet, and even when its installed on the target machine and running, its URI will be unknown to the client.

Lets start by getting the web reference. Create a new ASP.NET web service project (call it tempservice or something, you wont need to keep it for long) go to the Service.asmx code behind and paste in the code from your WebServiceCode.cs file. Then right click the Service.asmx file and View in Browser. Copy the URL from the browser window that pops up, and add it as a web reference to your main project (right click References, Add Web Reference, paste into field, click Go, click Add Reference).

Great we have a description of our web service for the client app to use when querying.

Create another class called WebServiceQuery. Add the following to the namespace references section:

 using System.Net;

Now create a public method called Query that returns a string (or you can just paste in the following code):

 public string Query(string targetMachineName)
      Web_Service_inside_a_Windows_Service.WebServiceCodeReference.WebServiceCodeWSE wsc = new Web_Service_inside_a_Windows_Service.WebServiceCodeReference.WebServiceCodeWSE();

      IPHostEntry ip = Dns.GetHostEntry(targetMachineName);
      wsc.Url = "soap.tcp://" + ip.AddressList[0].ToString() + "/MyLittleWebService";
      string result = wsc.GetMessages("some guid");

      return result;

NOTE: The object we create is the WSE version (WebServiceCodeWSE), without this the calls to soap.tcp will not work.

Simple – first we instantiate our web reference object. Then we set the URI of the newly instantiated object the same way we did for the service itself. Finally we query the service and return the value. Note the GUID parameter on the service call – this is just in there to demonstrate calling methods and passing in parameters, but you already knew how to do that.

Now you can create a test application, start the service and then query it! All that’s left is to create a Windows service and create an instance of your calling class.

Just a note on the URI creation parts – if you are getting an error do do with port parsing, check that the IP address its getting isn’t and IPV6 address…

Okay so that’s it, my first post. Its long and boring.

Next time I will visit security using SOAP headers and how to encrypt the SOAP data using AES (Rijndael).