WCF Services hosted in IIS

Lately, I had some trouble hosting WCF Services on IIS on a remote VM running Windows Server 2003. Nothing really serious, but I figured out that it wouldn’t be bad to write down these errors for future reference.

Enabling hosting of WCF Services on IIS

This is probably trivial, but I’m still writing it here so I can refer to it later.

First, if the .NET 2.0 Framework was installed prior to IIS, IIS is not registered with ASP.NET. It can be done manually running the following command:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis -i

Then, you have to register .svc files in IIS, which is done by running the following command:

C:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Communication Foundation>ServiceModelReg.exe -i

Once this is done, simply run iisreset in any command line window to restart IIS.

That’s it, IIS can now host WCF services.

Please note that if you deploy your website directly from Visual Studio, you’ll have to make sure that Frontpage Server Extensions are installed on the server.

Hosting a WCF Service in IIS

Anyway, hosting the service is very easy. The service endpoint will be a .svc file in which you’ll have to write only one line, referencing the service that is to be hosted.

<%@ ServiceHost Service="MyService" %>

On top of that, the Web.config file has to be modified in order to contain the service’s information like you would do in any WCF host application (ABC, except that you leave the address empty as the endpoint is the uri of the .svc file).

Permission Issues

If the service you are hosting interacts in some way with the file system or any other operation that might require permissions, don’t forget that once they are in IIS, they will have the limited rights of ASPNET (XP) or NETWORK SERVICE (WS2003) account, depending on the operating system.

I’m highlighting this because prior to host my services in IIS, I hosted them in a command line window. This is handy for debugging, and very simple to set up. However, this means that the WCF services are running with lots of privileges (power user or administrator, as you are developing). Once in IIS, you can still debug easily by attaching to the IIS process (Ctrl + Alt + P in Visual Studio).

Extension Methods and null Objects

C# 3.0 allows adding new methods to existing types. These are called Extension Methods. This allow programmers to add methods to existing types, even if they are not partial or event sealed.

These special methods have to be declared in a special way:

  1. They must be declared within a static class
  2. They must be static
  3. The first parameter of the method has to be the type that is "extended", preceded by the this keyword

So, for example, let’s copy the very useful IsNullOrEmpty method as an extension method.

public static class Extensions
{
    public static bool IsNullOrEmpty(this String s)
    {
        return String.IsNullOrEmpty(s);
    }
}

Simple. Calling this

String s = "";
s.IsNullOrEmpty();

returns true. You can even do

"".IsNullOrEmpty();

which returns true as well.

Now, all of this is actually an illusion. When the compilers finds

"".IsNullOrEmpty();

he will translates it in

Extensions.IsNullOrEmpty("");

So, when an extension method is used, there is one more parameter, that is of the type the extension method is defined on. In this case, String.

But, if it as parameter, it can be null, right? Yes!

String s = null;
s.IsNullOrEmpty();

or even

((String) null).IsNullOrEmpty()

will both work, without trowing a NullReferenceException.

Nothing revolutionary here, but I found funny to "call" method on a null object and not have an exception raised.