Scenario
You have this Windows Communication Foundation (WCF) service that runs on plain old vanilla Internet Information Services (IIS). Somewhere along the line, you want to convert this service to run on SharePoint. You’d like to achieve this conversion with a minimal amount of effort because you’re basically inserting another layer into the stack which is essentially unneeded.
There’s a lot of information out there about this topic, but most of it is about how to create a SharePoint version of the web.config and service. These all center on using some sort of Factory to spool up the service and such. While that’s great and all, it’s basically like rewriting your service from the ground up because you won’t have a web.config and everything will have to conform to the factory framework.
There ought to be a better solution to this problem instead of writing the service again for SharePoint. Thankfully, there is.
SharePoint hosts its web services in the _vit_bin virtual directory, which maps to the ISAPI folder in the SharePoint hive (C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14ISAPI). Fortunately, you can map this folder in a SharePoint project and deploy your service there too! Plus, if your service is in .NET 3.5 or earlier, you don’t need to change a single line of code. You just need a new .svc file and a web.config in your subdirectory within the ISAPI folder.
Note: You shouldn’t be deploying directly to the ISAPI folder because you could overwrite important SharePoint services and configuration files. Instead, do like you would for a Feature and create a subdirectory.
Deploying to a subdirectory allows you to deploy your own custom web.config that won’t affect anything else within SharePoint except your service and anything else hosted from the directory. It’s exactly like creating a Web Application in a SharePoint deployment package.
In a future post, I’ll show you how to take advantage of web.config transforms to mimic in a SharePoint project what you can do in an ASP.NET Web Application project.
Solution
There are several manual steps, but the only thing from your existing service that you need are its requisite DLLs. For my example, I’m going to have my SharePoint project be in the same solution as my WCF service, but that’s not necessary. I also assume that you already have a SharePoint project set up and that your service and all of its dependent assemblies are strongly named. If they aren’t, you need to do that before starting, because SharePoint won’t deploy an assembly that isn’t strongly named.
Mapping to the ISAPI folder:
In your SharePoint project, right click the project file and navigate to Add > SharePoint Mapped Folder…. From here, select the ISAPI folder, not any subdirectories, and click OK. This will add the ISAPI folder to your project as a mapped folder.
Adding Your Custom Folder:
Now that you have the ISAPI folder added, right click it and select Add > New Folder. Give the folder a name and hit <Enter>.
Copy Your Web.config and .svc Files:
Now that you have the folder you need, you simply need to copy over the web.config and .svc files that you need. This should be a simple copy-paste. If you have any code behind for the .svc file, you can delete it. We’ll modify the .svc file later.
Add the WCF Assemblies to the SharePoint Package:
Now you need to add modify the SharePoint Package to make sure that your WCF service and its dependent assemblies are deployed to the GAC so SharePoint can see them when it tries to load your service.
To do that, double click on the Package in the SharePoint Project and select the Advanced tab at the bottom of the Package Explorer. This is where you add additional assemblies to be deployed to the GAC and marked as Safe.
Once here, click the Add button and choose either Add Existing Assembly… for an assembly that isn’t in the current solution or Add Assembly from Project Output… to grab an assembly from another project in the solution. Since I’m working in the same solution as my service, I’m going to choose Add Assembly from Project Output….
Here you can choose the Source Project or assembly from the drop down or browse box. Once you’ve located your assembly, it will appear in the Location box. The next step, however, is the most important and the most often overlooked.
Adding the Assembly to the Safe Controls List:
It’s one thing to have the target assembly included in the SharePoint WSP, it’s another thing entirely to have it deployed as a safe control. So you’ll want to click Click here to add a new item to add the Safe Control. You’ll need to provide the Namespace and the strong name of the assembly, including the PublicKeyToken. Be sure to mark the control as Safe!
Modify the .svc File to Reference Your Service Indirectly:
Now that your service’s assemblies are in the Global Assembly Cache (GAC), you need your .svc file to reference it correctly. Open the .svc file and change the Service attribute to the concrete service class and the strong name of the assembly:
Deploy and Test Your Solution:
Now you should be able to deploy and test your solution and it should function exactly like it did when it was running outside of SharePoint.
One thing to keep in mind: the authentication schemes need to match between SharePoint and your service, so if your service allows anonymous authentication, SharePoint must to or you’ll get an error. SharePoint defaults to NTLM authentication only.
