Recently I got interested in Windows Communication Foundation (WCF) Services and SharePoint. I’ve heard some great stories about how WCF can improve the architecture of your solutions. On the other hand I’ve heard some complaints about how complex the integration with SharePoint is. To keep it short: reason enough to check it out myself.
Hello World
To be honest I haven’t worked with WCF services yet. Somehow the new technology passed me and I didn’t even give it a chance. Recently I stumbled upon Daniel Larson’s book Developing Service-Oriented AJAX Applications on the Microsoft Platform. Not surprisingly Daniel heavily uses WCF services to show us what can be achieved using ASP.NET 3.5. Reason enough to try some things out myself.
So how do you start with WCF and SharePoint? Sahil Malik did a great job covering that particular subject. Sahil wrote a series of topics covering almost every aspect of the process of working with WCF in context of SharePoint: from creating the directory hosting the WCF services, through configuring the SharePoint Web Application to accept WCF requests, to deploying WCF end points as solutions.
One of the steps in configuring a SharePoint Web Application to handle WCF requests is to register a Virtual Path Provider. It turns out that SharePoint doesn’t handle requests to .svc files properly. Sahil did a great job and created a CodePlex project called Winsmarts SharePoint WCF Support which contains all the components required to make it work. The downside is that Sahil didn’t create a SharePoint Solution (.wsp) for it, so you’d have to make one yourself. It’s absolutely worth doing as it’s something you’ll be using in all your SharePoint+WCF projects. I chose the simple approach and used WSPBuilder to get the job done. I copied Sahil’s code, wrapped it in a project and used WSPBuilder to create a Solution for me. To spare you that 10 extra minutes of work I published my WSP on CodePlex @ http://imtech.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=28399.
Following Sahil’s instructions I was quite fast up and running: I had my custom WCF service running on a SharePoint Web Application:
Then I decided to take it a step further and check if it properly handles SharePoint context.
Why is context so important?
Every request you make in ASP.NET is wrapped in a context object. That object contains a lot of information including current location, authenticated user, etc. SharePoint uses that mechanism too. Every request made towards a SharePoint site is wrapped in an instance of the Microsoft.SharePoint.SPContext class. Comparing to the plain ASP.NET context object, the SPContext contains a lot of valuable SharePoint-specific information including references to the current Site Collection (SPSite), Site (SPWeb), List (SPList), Item (SPListItem), etc. Considering that almost every action you would perform using a WCF service on SharePoint requires one of these objects it is very useful to have them around instead of instantiating them yourself.
SharePoint context magic
How the context works? If you’ve been working with SharePoint you probably know of the _layouts Virtual Directory. In IIS Manager it looks like a regular IIS Virtual Directory. The cool thing is the SharePoint magic that happens behind the scenes: you can append _layouts to every existing path on your SharePoint site and while it still points to files located in 12\TEMPLATE\LAYOUTS on your web server, it instantiates context objects based on the URL, eg. http://moss/_layouts/settings.aspx opens settings for the Root Site but http://moss/PressReleases/_layouts/settings.aspx opens settings for the Press Releases Site. In both cases we’re requesting the same settings.aspx page located in 12\TEMPLATE\LAYOUTS but it does different things depending on the URL used to call it. See the magic?
Following Sahil’s advice to keep the things clean, I have decided to create a directory called _wcf under the root of my Web Application. Additionally I have created a Virtual Directory pointing to it:
Unfortunately the SharePoint magic wasn’t working for me:
It turns out that the SharePoint magic works for Virtual Directories owned by SharePoint not all Virtual Directories under a SharePoint Web Application. That takes us to two conclusions.
context != context
There is context and context that we’re talking about while referring to a WCF service running on a SharePoint Web Application. The first one is all about making a WCF service available through the URL of a Web Application using the SharePoint technologies. The request gets authenticated and you are able to get some information using the SPContext object. Let’s call it SharePoint context.
The second context is the Site Context. Remember how we were able to call one and the same settings.aspx page in context of different sites (Root Site and Press Releases Site) and make it behave differently depending on the URL? Site Context is all about being able to fully benefit of the context information provided by SharePoint and leverage it for your purposes. As far as I know such functionality is available to Virtual Directories owned by SharePoint only. While debugging the custom Virtual Path Provider I’ve found out that a request to http://moss/PressReleases/_wcf/SharePointTestService.svc is being passed to the Virtual Path Provider as ~/PressReleases/_wcf/SharePointTestService.svc A similar request to http://moss/PressReleases/_layouts/settings.aspx is being transformed to ~/_layouts/settings.aspx before it even hits the Virtual Path Provider! See the difference?
Once again it’s all about context
The second conclusion takes us to a question: do you really need Site Context in your WCF service to make it useful? It depends on what it is supposed to do and how you will leverage the functionality. Theoretically you would be able to get to the data in SharePoint even without the context object. As your service is running on a SharePoint Web Application you could instantiate a reference to Site Collection and all other objects you might need.
Whether your WCF service requires context or not determines your deployment process. WCF services that depend on Site Context must be deployed in one of the Virtual Directories owned by SharePoint: preferably _layouts or _vti_bin (where all SharePoint web services are located by the way).
Many people are concerned about deploying to locations owned by SharePoint. First of all there is a chance that a SharePoint update or a Service Pack, or a future version might deploy a file with the same name to the same location. Any existing file would be overwritten. You could mitigate this by creating a subfolder and store your files there. Choosing a non-general name (something else than wcf) might be a wise choice if you want to be sure that nobody will overwrite your files.
Another thing many people worry about is the security: everything you put in one of the SharePoint’s Virtual Directories is available across the whole Farm. You could partly suppress this by deploying the service’s assemblies to a specific Web Application. Everyone who would try to reference the service through a different Web Application would get a nasty error. It’s not a perfect solution but it could help you to solve some security issues.
On the other hand there might be situations when you won’t be needing the Site Context. In such scenario you can create a Virtual Directory under your SharePoint Web Application and everything will work just fine. One more question you should answer before you make your choice is: just because your service doesn’t need the Site Context today, are you sure it won’t be needing it tomorrow?
Summary
WCF services are really powerful and can improve the architecture of your solution. Deploying WCF services to a SharePoint Web Application requires you to configure some components which make calling WCF services possible. While WCF service give you great power of providing data stored in SharePoint to external clients, you have to consider a few things before you determine the architecture of your solution.
June 7th, 2009 at 5:42 pm
Waldek,
You mention early in the post about using WSPBuilder to make the deployment of the WCF code easier. If you start to implement custom Virtual Directories and folders then you will not be able to leveage the WSP deployment infrastructure and will have to look at alternative solutions. I personally like to stay within the bounds of the WSP framework and apply logic and code to deal with my specific security requirements.
Andrew
June 7th, 2009 at 8:35 pm
@Andrew: definitely agree with you. WSPBuilder is to help you to do the easy/common stuff, but as soon as you will want to deploy something more complex you will have to do it yourself. On the other hand, you can deploy your WCF services to _vti_bin and that can be done from within a regular WSP and thus using WSPBuilder, right?
June 8th, 2009 at 10:43 am
I think you cannot create subfolders using the solution framework, doesn\'t matter if you are using WSPBuilder or not..
Or are you creating the subfolder using a featurereceiver or timerjob in combination the SPIISSettings class?
June 8th, 2009 at 11:12 am
@Robin: You can: I've been deploying Feature images like that to a custom directory under Images. There is no magic to it: just include the file with the right path in the Manifest.xml and SharePoint will do the rest.
June 8th, 2009 at 1:04 pm
Yeah, I\'ve put it wrong ;) I meant, creating IIS virtual directories using the solution framework (like you\'ve done with _wcf folder).
June 8th, 2009 at 1:13 pm
@Robin: ;) You're right then. You would have to create a timer job to get it done. But then again: why not deploy the service to _vti_bin?
June 8th, 2009 at 1:17 pm
Exactly! :)
June 9th, 2009 at 12:51 pm
Just curious and I don't have a SharePoint VM to test with me – but are you using aspNetCompatibilityEnabled="true" in your WCF web.config?
June 9th, 2009 at 12:55 pm
@JohnLiu: I do, but I haven't make it a part of the Feature. It's something I would deploy with the WCF service itself.
June 9th, 2009 at 3:11 pm
Oh I realized I read the article wrong and made a wrong comment.
I was looking at rolling a custom VirtualPathProvider
http://msdn.microsoft.com/en-us/library/system.web.hosting.virtualpathprovider.aspx
And hooking it up with HostingEnvironment.RegisterVirtualPathProvider which should allow you to 'chain' your virtual path provider on top of SharePoint's one.
Then you can handle VirtualPathProvider's GetDirectory and GetFile and map it back to the root site's _wcf folder.
June 15th, 2009 at 2:46 pm
Haha I read about this: http://spwcfsupport.codeplex.com/ only a couple of days later – they did exactly the virtual path provider thing. Check it out!
I think it's great to roll your own, but sometimes I get lazy ;-P
June 15th, 2009 at 4:09 pm
@JohnLiu: Sahil was first: I only copied his code (exactly the same as in spwcfsupport) and wrapped it in a WSP. I think just yesterday Sahil wrapped his code in a WSP as well.
February 2nd, 2010 at 9:42 pm
Waldek, if I read this correctly, you are able to get SPContext.Current within a .svc. If that is true, how? If it is just a matter of the folder and the compatability option, I'm still doing something wrong. Thanks,
Tom
February 3rd, 2010 at 4:28 pm
@Tom: that's a good one. It's been a while since I was working on that, so let me just try: have you tried hosting your WCF service within the path of a SharePoint Web Application? Additionally you could try to use the Feature that I put on CodePlex to get the configuration settings into your web.config.
February 3rd, 2010 at 4:33 pm
It's second hand, but I was told the service is in the _vti_bin folder of a SharePoint Application and we are using similar, if not the same settings from your web.config. Did I misinterpret your context statement? I'm really curious if you have SPContext in your service and I'm just missing something or if SPContext just won't work.
May 25th, 2010 at 10:46 am
Hi Waldek, Great Post!!
I am currently migrating a site from MOSS 2007 to SharePoint 2010 which has custom WCF services. When deploying .wsp file in MOSS 2007 environment it gets deployed at Features directory under 12 hive and works well. Where as when I try to deploy the .wsp file in SharePoint 2010 the WCF doesn't work.
The service is working correctly when the .svc is stored directly in the virtual directory of the iis… the problems appear when I deploy the .svc file to the 14. Any idea?
I didn't change anything, only put the .svc outside SharePoint to test it, and it works. When I call the .svc file inside SP I get this error:
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable.
Apart from that when I deploy the .wsp file (its a custom site template ) and create a site, the default webservices also doesn't work (_vti_bin\Lists.asmx , _vti_bin\Listsdata.asmx..etc)… I have verified for the webservices by creating a normal team site and browsed for _vti_bin webservices which works fine.
Is that the way WCF behaves differently in SP2010 environment?
May 26th, 2010 at 11:38 am
@Sheetal: have you tried deploying your custom SVC alongside SharePoint services? Additionally have you looked how SharePoint services have been configured?
June 2nd, 2010 at 6:46 am
Hi,
I had to register the HttpHandler in the tag in web.config and it started working.
I am not able to figureout how the SharePoint services been configured.
June 2nd, 2010 at 6:46 am
Hi,
I had to register the HttpHandler in the <system.webserver> tag in web.config and it started working.
I am not able to figureout how the SharePoint services been configured.
July 17th, 2011 at 3:20 pm
[...] http://blog.mastykarz.nl/wcf-sharepoint-context/ [...]
July 21st, 2011 at 3:41 pm
[...] http://blog.mastykarz.nl/wcf-sharepoint-context/ [...]
November 8th, 2011 at 11:59 pm
Hello Waldek, hey have you tried creating the WCF (simple Hello World) in SP 2010 and host it in the ISAPI folder of the same web-application (SP 2010). Make sure that Sharepoint web-app is using claims authentication. Now run the WCF from the SharePoint context and check what is the identity the WCF code is running under, it turns out it is app-pool identity of the web-app and not the end user identity/claim.. I think this is not correct as the WCF code shld run under the end user identity and not app-pool. Have you experience it? Any thoughts around it?… Not sure how the out of the box WCF services in SP 2010 work seamlessly in claims authentication…
November 9th, 2011 at 7:16 am
@MossBuddy: I have to admit that I haven't stumbled upon such scenario yet. Have you tried asking on MSDN SharePoint Forums?
November 9th, 2011 at 7:19 am
WCF is very simple in SP2010 now, start with CKS for VS.NET 2010, and use the project item template for WCF Service.
The magic in SP2010 are the three SharePoint service factories that does a lot of the plumbing that we didn't have in 2007.
November 9th, 2011 at 1:56 pm
Thanks John Liu:- have u tried the stuff with cliams enabled web-apps…they dont pass the end user cliam easily you have to follow what Steve Peschka from microsoft has said in his blog….