Deploying webservice SVC file NOT to ISAPI?

Question

Is it possible to deploy the SVC file to something other then the ISAPI folder of SharePoint. Basically I'd like my solution to be webapplication scoped, so that the webservice cannot be called from other web applications then the one I deploy them to.

If you place your SVC file in the ISAPI folder and the DLL in the GAC, then the service can be called from every web application, since the ISAPI folder and GAC are shared.

Update: I now deployed my code via a solution and manually placed a SVC file into the inetpub dir. I don't believe deploying stuff to inetpub is an option with SharePoint solutions, is it? There are a couple of downsides to this approach: - Working in a farm environment, this would mean I'd have to manually deploy the SVC to each front end machine. But that's something I could script I guess. - When I extend an application to a different access mapping, the new inetpub dir would have to get the SVC too. - When I update the version number of my assembly, I'd have to update all SVC files too. But that too can be scripted.

The major advantage is that my service is now limited to a single web app.

The thing I don't really understand though: how do they do this stuff at larger hosters? Or is deploying webservices simply not an option there? I really like the multi tenant approach SP2010 offers, but I wish they would have taken it just a bit further then they have.

Answer 1

This might be slightly hacky, but it works:

You can deploy from WSP to the inetpub folder by using the ApplicationResourceFiles element in your solution manifest. For more information: http://msdn.microsoft.com/en-us/library/ms463158.aspx

If you are creating the WSP as a Visual Studio 2010 SharePoint project, you can do it this way:

1. Add New item... 'Empty Element' to your project.
2. Delete the elements.xml file which it creates.
3. Add your .svc file into the element.
4. Right click the .svc file and pick properties.
5. Under deployment type, set it to ApplicationResource
6. You can customize the Deployment Location, however it will always be under the Resources folder of your inetpub folder (couldnt find a way around this yet)
7. Make sure the element is added to your package, and not to any other features.
8. Deploy and you will find your service at http://webapp/Resources/service.svc

One thing I would note though, as Renzo suggested I would also recommend having code which verifies the current context. The virtue of having your .svc in ISAPI is that your service methods will have access to SPContext and all that that brings.

Answer 2

How about handleing that on your service code instead doing some verification using the current context, user etc ?

Answer 3

I think there are likely different schools of thought here, but I have had projects that had non-SharePoint dependencies. For the longest time, most of my custom services were deployed to a standard IIS web on the server. The downside with this approach is that you lose out on SharePoint's robust Packaging and Deployment model which means each web server has to be manually kept in sync. In addition, the Context is not available as it has been mentioned.