What should you do?

You are hosting a Windows Communication Foundation (WCF) service under Microsoft Interent Information Services (IIS) 7.0.
You have set up a web site in IIS Manager. The physical path is c:\wwwroot\Calendar.
There is a Calendar.svc file in the c:\wwwroot\Calendar folder. It contains the following directive:

<% @ServiceHost Language=”C#” Debug=”true” Service=”Calendar.Calendar” CodeBehind=”CalendarSvc.cs” %>

The CalendarSvc.cs file contains the source for the Calendar class in the Calendar namespace.
You compile this code into the Calendar.dll file. You need to deploy your service to the web site. What should you do?

A.
Copy the Calendar.dll file to the c:\wwwroot\Calendar\code folder

B.
Copy the Calendar.dll file to the c:\wwwroot\Calendar\bin folder

C.
Copy the Calendar.svc.cs file to the c:\wwwroot\Calendar\bin folder

D.
Copy the Calendar.svc.cs file to the c:\wwwroot\Calendar\code folder

Explanation:
There are basically two options of WCF deployment in IIS:

Option 1 – “bin” deploy (preferred option)
1. compile your WCF service into a DLL (class library)
2. create a website in IIS6
3. copy the WCF DLL’s into the website’s .\bin folder
4. create a *.svc file in that website
5. add an appropriate web.config in the website folder to define your endpoints and service configuration etc.

Your WCF service will now be reachable at the website’s base address, plus the name of the *.svc file, e.g.
http://myserver/someweb/Myservice.svc

Your *.svc would look something like this:
<%@ ServiceHost Language=”C#” Debug=”true” Service=”WCF_Simple_Service.HelloIndigoService” %>
The Service= attributes denotes the class implementing the service – fully qualified with its namespace.

Option 2 – put stuff into App_Code
1. create a website in IIS6
2. put all your WCF related *.cs files directly into the .\App_Code folder
3. create a *.svc file in that website
4. add an appropriate web.config in the website folder to define your endpoints and service configuration etc.

Your WCF service will now be reachable at the website’s base address, plus the name of the *.svc file, e.g.
http://myserver/someweb/Myservice.svc

Your *.svc would look something like this:
<%@ ServiceHost Language=”C#” Debug=”true” Service=”Service”
CodeBehind=”~/App_Code/Service.cs” %>

A simple, sample web.config might look something like this:

<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name=”WithDebug”>
<serviceMetadata httpGetEnabled=”true” />
<serviceDebug includeExceptionDetailInFaults=”true” />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled=”true” />
<services>
<service name=”SimpleWCF.HelloIndigoService” behaviorConfiguration=”true”>
<endpoint
address=””
binding=”basicHttpBinding”
contract=”SimpleWCF.IHelloIndigoService” />
<endpoint
address=”mex”
binding=”mexHttpBinding”
contract=”IMetadataExchange” />
</service>
</services>
</system.serviceModel>

You basically define your <service> tag – and again: the name= denotes the class implementing the service – fully qualified with its namespace.
It must contain at least one endpoint – since IIS6 only support HTTP, you can use basicHttpBinding or wsHttpBinding and that’s about all there is.
A “mex” endpoint is optional – but very useful, especially for development and testing.
It allows client to “discover” the service and get its service description so it can interface with it.

Once your service is deployed in IIS, you can see it in action using a tool like the WCF Test Client that ships for free with WCF,
or SoapUI which is a general-purpose SOAP testing utility (with a free edition for you to use).