Generally, when creating a service to be exposed as a web service, I have built the entire service project(s) (including datacontract/entity classes) outside of any web project, in a separate solution. These projects can then be built and tested without any web project getting involved. I then usually create a separate web project, that acts solely as a http end point, and which references and uses the actual web service project(s) . To facilitate this, there is a 1:1 mapping in the asmx code behind which simply defines the webmethod and passes through or calls upon the real service class. What a waste of time and useless code.
When using the Patterns & Practices Web Service guidance, I noticed that just like I have always done, the real service classes are created in their own projects outside of the scope of a web project (for numerous good reasons), but I noticed that in the actual web project classes there was no code behind, and therefore no 1:1 mapping of each web method to the real service method. As simple as the explanation is, I scratched my head for a few minutes trying to determine how the actual service classes were getting invoked? In the words of Homer, "Doh!" In the Asmx @Webservice directive there is no codebehind attribute, and the class= attribute just references the fully qualified class name that implements the actual service methods. This requires the actual service project references system.web, and also requires that the public web method attributes are marked accordingly. But this is fine because the goals of separating the service implementation from the end point project are still accomplished, all without the useless 1:1 mapping in the codebehind.
Sometimes its the simple things. Oh well, I finally realize this now that .Net 3 is available and WCF changes the way we declare endpoints altogether. But, I wish I had realized this simple asmx endpoint trick a while back : -)