IIS WCF service hosting vs Windows Service

Question

We developed a WCF service and we're looking to deploy it. Our clients will be using it with basicHttpBinding but our internal team will be using it with namedPipesBinding.

We are wondering if is it better to host it in IIS 7 or with a Windows Service. 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 logical, right?

We also read on StackOverflow that the base address is ignored when a WCF service is host in IIS (see WCF service configuration file question regarding <baseAddresses>)

Solution 1

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.

Solution 2

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

Solution 3

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.

Solution 4

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

Solution 5

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.

View more solutions

Comments

[Jayee]

It always depends on the context. According to Microsoft "you shouldn't consider self-hosting for enterprise scenarios. Self-hosting is suitable during the development or demonstration phases of your enterprise project" msdn.microsoft.com/en-us/library/bb332338.aspx

[esylvestre]

You're right, but before asking myself these questions, I want need to know if the intial configuration of my service (bindings) can be managed by IIS.

[esylvestre]

This is exactly what I was looking for, but I would like to know if there are tools to manage WCF services when they are self-hosted ? Actually, The main point of hosting it in IIS was to give a user friendly tool to configure our services.

[esylvestre]

"Dublin" is probably the tool I'm expecting. Thank you very much.

[marc_s]

The management story for WCF isn't brilliant right now - Microsoft promises a lot more tool support with "Dublin" (Server add-on to ship sometime after .NET 4.0)

[Piotr Owsiak]

I completely agree, plus you can create a custom ServiceHostFactory to get more control over your ServiceHost.

[user55474]

does the http binding also needs to exist along with net.tcp. if i only have net.tcp in the binding will be service be activated

[Dasith Wijes]

Also "easier" to manage SSL certificates and htttp port bindings through IIS.

[Dasith Wijes]

To Quote disadvantages of self hosting: Limited features: Self-hosted applications have limited support for high availability, easy manageability, robustness, recoverability, versioning, and deployment scenarios. At least, out-of-the-box WCF doesn't provide these, so in a self-hosted scenario you have to implement these features yourself; IIS, for example, comes with several of these features by default. Microsoft says self hosting is not an enterprise solution for services exactly for these reasons. See the comparison here msdn.microsoft.com/en-us/library/ms730158.aspx

[StingyJack]

As a recent anecdotal example, hosting the same net.tcp message logging service in IIS consumes 3x more memory and handles 1/2 the number of requests as when "self" hosting the same service in a Windows Service.

[Cheeso]

wow @StingyJack that's good information. What version of Windows Server?

[StingyJack]

Mostly windows 7 pro but some windows 10 and 2012 server also (the usual target is more of an "appliance" than a general purpose server). It could still be a configuration setting that is bogging down IIS that I haven't found. I do find it hard to believe that it cant keep up with self host as far as the # of requests.