IIS WCF service hosting vs Windows Service

To answer at those question :

We ran some tests and we found out that when we're adding bindings in IIS, it doesn't update config file of our service. That means that we would need to maintain the configuration in two different places. It's not logic, right ?

When you use IIS to host your service, you must configure your App.config file or web.config file to allow IIS to expose some binding, so in your configuration file, you will put all your binding you allow to your wcf service. Http, net.tcp etc...

In your binding you will not specified address, because you will specified those address in IIS directly.

In IIS you must allow the binding available in the advanced settings of your web site. After that you will set new binding for your web site "web service" and add every bindings you want listen, and specify the address.

You will specify the address directly in IIS.

There's an example.

Your configuration file:

<services>
    <service name="ServiceName">                    
        <endpoint address=""
            binding="basicHttpBinding"
            bindingConfiguration="httpMode"
            contract="IContract" />                 
        <endpoint address=""
            binding="netTcpBinding"
            contract="IContract" />
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
    </service>
</services>

In your IIS advenced setting your will put

http,net.tcp in Enabled Protocols

After that you will go in your binding into IIS. Put your binding for http normaly and add a new binding net.tcp, in the binding configuration put the port and virtual directory like

8001:*

This setting allow all connection into the 8001 port for any virtual directory.

You also must to have the feature "WCF Activation, (Http activation and Non-Http Activation)" installed on your server.

Hosting in IIS has many pros and many cons.

Yes, IIS gives you on-demand loading - this can be a plus or a minus. When a request comes in, the ServiceHost is constructed, then the service class being hosted is instantiated, and the request is handled. Nothing needs to be running around the clock. But at the same time, this setup requires more time and effort every time a message comes in, and you as a programmer don't have much control over your service host, really.

And yes, with IIS, the virtual directory where the *.svc file resides defines your address - any base addresses or explicitly defined addresses in your config are disregarded. And without much effort, you cannot change the layout of the service addresses - they're always going to be http://servername/virtualdirectory/YourService.svc (including the .svc extension).

Self-hosting is often times faster, since your ServiceHost is already up and running - but it's up to you to make sure it really is up and running, there's no "on-demand" loading whenever a message comes in - either it's up and can service the request, or not. But you have a lot more control over the service host - when and how it's constructed etc., and you get to pick and define your service addresses as you see fit.

I personally would almost always choose to use self-hosting - in a console app for testing, in a NT service for production. To me, it just seems the more appropriate way to do it, and the more controlled way, too. You have to do more work - but you know exactly what you're doing.

Marc

marc_s usually gives great answers that I agree with completely, but in this case I don't.
Self-hosting of WCF is not a good idea, especially with the Dublin technologies being released soon by Microsoft. The management and operations of WCF (and WF) applications is much simpler when hosted inside IIS.

In addition you get the on-demand loading.

There is an always-on option for IIS7.5 (WS2008 R2).

And you can easily do URL rewriting to omit the .svc if that bothers you.

Interesting tidbit-> after reading this thread I came across these words in the MSDN about hosting a WCF service using a Windows Service:

The following are some of the disadvantages of Windows services:

•Deployment: Services must be installed with the .NET Framework Installutil.exe utility or through a custom action in an installer package.
•Limited features: Windows services still have a limited set of out-of-the-box features to support high availability, easy manageability, versioning, and deployment scenarios. Essentially you have to cover these requirements yourself through custom code while, for example, IIS comes with several of these features by default. Windows services do add recoverability and some security features, but you still have to do some work yourself.
http://msdn.microsoft.com/en-us/library/bb332338.aspx

...and the following link:

Hosting Services: (nice comparison chart)
http://msdn.microsoft.com/en-us/library/ms730158.aspx

There is no standard answer to this question. I disagree completely with the answer from Cheeso (Self-hosting of WCF is not a good idea).

Please check following links: (http://msdn.microsoft.com/en-us/library/ms730158.aspx, http://msdn.microsoft.com/en-us/library/bb332338.aspx) and think about your constrains:

• operative system
• expected performance
• available HW
• expected availability

and you will see that in many situations "self hosting" is the best alternative.

IIS provides you with a lot of out-of-the-box features, like app domain reloading, monitoring and so on.

This is why you should answer this questions first: do you need all this features or not? If not - windows service can be considered.

Although there is selected answer here, I will allow myself to post a Q/A thread link.

How to configure WCF service from code when hosted in IIS?

What you will find in my answer there (and the link in it) is your fine control over the service host whether you load it in WService or in IIS.

Upon service start you can interogate IIS what bindings does it have and create the appropriate endpoints. Look for IIs configuration throught Microsoft.Web.Administration namespace.

Hope this helps a bit.