Table of Contents for SharePoint as a WCF host.
- Basics -
1. Create a WCF Home. This is the virtual directory that will host all your WCF endpoints.
2. Create a WCF Service Library, and throw it in the GAC.
3. Create a relevant .svc file in the WCF home you created in step #1.
4. Write a WCF Virtual Path Provider, and register it in the SharePoint site.
- Real world -
1. Adding WCF Support to a website.
2. Deploying WCF EndPoints as solutions.
Okay good, so you created a _wcf home
, and you created a service in a service library
. The service library is in the GAC.
The next step is to create a .svc file.
Well, here is how my HelloWorld.svc looks like -
<%@ Assembly Name="HelloWorld, Version=220.127.116.11, Culture=neutral, PublicKeyToken=0512278251be14ea"%>
<% @ServiceHost Service="HelloWorld.service1" %>
Well, is that enough? Not nearly. You haven't specified the endpoint details yet.
In the same _wcf home, create a web.config that looks like this -
1: <?xml version="1.0" encoding="utf-8"?>
5: <service behaviorConfiguration="HelloWorld.service1Behavior" name="HelloWorld.service1">
6: <endpoint address="" binding="wsHttpBinding" contract="HelloWorld.IService1" />
9: <add baseAddress="http://moss2007/_wcf/" />
16: <behavior name="HelloWorld.service1Behavior">
17: <serviceMetadata httpGetEnabled="true" />
18: <serviceDebug includeExceptionDetailInFaults="false" />
As you can see above, very very similar to hosting it in a plain vanilla IIS website, I have specified endpoint details. The important/interesting thing to note here is that the base address - is your WCF home.
Great you should be all set huh? Not nearly.
If this was plain vanilla IIS/ASP.NET, then you would have been all set. But go ahead and try accessing your .svc file at http://moss2007/_wcf/HelloWorld.svc and you will be greeted by the below:
What is going on??
Well, after having banged my head with reflector for a few hours, I figured out that the SPVirtualPathProvider isn't coded to handle URLs that start with '~'. (Seriously!).
Anyway, luckily ASP.NET is extensible, so I'm gonna write my own Virtual Path Provider to fix this issue.