Deploy custom web service to sharepoint server(2007/2010)?

According to MSDN, for deploying custom web service, we need to create *wsdl.aspx and *disco.aspx files, and put them with .asmx together under _vti_bin folder (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\isapi). And put the dll under bin folder of the root of sharepoint virtual directory. It works correctly for me.

However, i also found that if i put .asmx f开发者_如何学Cile under the root virtual directory without creating those *wsdl.aspx and *disco.aspx files. It can work as well and much easier than the above way. So i'm wondering what's the potential issues in this way?

Without the WSDL and DISCO files, folks' web service clients/consumers may have a hard time "discovering" your service's contract. If that's not a concern for you, don't worry about it.

I have created several web services in SharePoint 2007 that were simply deployed as http://.../_layouts/mySubFolder/service.asmx. It works! For SharePoint it does not matter whether the presentation layer is HTML or XML for a web service (in both cases security must be applied, can be addressed both as http://server/_layouts/mySubFolder/service.asmx and http://server/sites/subsite/_layouts/mySubFolder/service.asmx

Things that are wrong thing about it

• the word "layouts" implies "something to do with how it looks like".. which is not the case when we speak about web services
• when migrating to SPS2010 where WCF services come into play, it will be different. However, I have not yet played with SPS2010 and do not yet know, how different. (Somehting about it here - http://blog.mastykarz.nl/wcf-sharepoint-context/)

Quite an old post but just thought i'd add to this as I don't believe the responses to date give the relevant detail on why SharePoint is setup this way.

The reason why you deploy webservices to ISAPI\vti_bin for SharePoint is because there are specific modifications made for requests to this folder to allow SharePoint to build an accurate discovery and WSDL file for the service based on the current virtual path of the service, not the path in the IIS site.

More specifically wsdisco.aspx and wswsdl.aspx handle requests to this virtual directory and will call the relevant disco.aspx and wsdl.aspx to generate the discovery xml or wsdl xml correctly based on the current SharePoint url.

If you add a service reference to your project for http://sharepointsite.com/sitecol/subsite/_vti_bin/lists.asmx the context for requests made on that url will be relevant to /sitecol/subsite as you would expect.

However if you add a service reference to http://sharepointsite.com/sitecol/subsite/_layouts/MyCustSvc.asmx the context will be fixed to http://sharepointsite.com/ because the default wsdl generator for ASP.NET is not aware of the SharePoint virtual paths. In which case calls to SPContext in the service will not work as expected.

There is an excellent post here with examples explaining this: Where do you deploy custom SharePoint web service files to?