Hosting a WCF Data Service in SharePoint (2013)
Hosting a WCF Data Service in SharePoint requires you to make a few important changes or else it will fail.
1. Change the servicehost Factory
If you created your WCF Data Service using VS2012 you will find that the servicehost Factory is set to
System.Data.Services.DataServiceHostFactory, Microsoft.Data.Services, Version=22.214.171.124, Culture=neutral, PublicKeyToken=31bf3856ad364e35
However, for WCF services hosted in SharePoint you can use other Factories that will take the burden of configuring endpoints, bindings and behaviors of your shoulders (http://msdn.microsoft.com/en-us/library/ff521586(v=office.14).aspx). Even though this information applies to SharePoint 2010, it’s still valid for 2013. So I ended up changing my Factory to
Microsoft.SharePoint.Client.Services.MultipleBaseAddressDataServiceHostFactory, Microsoft.SharePoint.Client.ServerRuntime, Version=126.96.36.199, Culture=neutral, PublicKeyToken=71e9bce111e9429c
2. Disable Impersonation
If you can access the service but none of it’s methods because ‘NT AUTHORITY\IUSR’ cannot logon, changes are that you need to update the Web.Config so that impersonation is set to false. That way IIS won’t use the IUSR account for impersonation.
<system.web>... <identity impersonate="false"> </system.web>
3. Add the connection string to the Web.Config (if you’re using Entity Framework)
If you make use of an Entity Framework you need to add the Entity connection string to your web service Web.Config file
4. Deploy Microsoft.Data.Services and dependencies to GAC
I had a couple of “misunderstandings” with NuGet as well as with the way the WCD Data Service packages are updated and deployed to GAC. In my case I ended up including the correct versions in my SharePoint WSP package for GAC deployment. But in reality, this simply should be a prerequisite before the application is deployed. The caveat with having the wrong versions referenced is that you may see errors indicating that the service type was not found. But reality a wrong version of Microsoft.Data.Services was loaded (188.8.131.52 instead of 184.108.40.206).
Some final thoughts …
Obviously it doesn’t make much sense in the SharePoint 2013 age to deploy web services to SharePoint’s ISAPI folder. The lower the number of dependencies on the base installation of SharePoint, the easier it is to upgrade to the next version. So of course you should create a remote app. But this would immediately increases the complexity as you need to implement proper authentication (and possibly authorization).