Your web  service assembly (dll) should be deployed to the GAC.

This should get you going:
msdn2.microsoft.com/en-us/library/ms464040.aspx

I did use the walk through. My asmx file is sitting in the ISAPI
directory and it references my dll in the GAC. But I've tried a web
part and a client application to consume and neither let me jump to
the code in the dll.

I've also tried this blog
www.sharepoint-tips.com/.../...oint-making-f5.html
(seems to be the one mentioning sharepoint  web service  debugging) and
I can't get it to work.

Where is your DLL? Have you deployed a PDB?

My dll is in the GAC. What is a PDB? Does that have anything to do
with disco or wsdl?

Debugging in the GAC is harder than in the BIN because you cannot copy
the PDB (VS.NET symbols) there using conventional drag and drop or the
GacUtil. There is a hack that I use that helps me debug assemblies
directly from within the GAC, but I'm not sure how conventional it is.

From Start > Run type the following command:
%systemroot%\Assembly\GAC_MSIL

Locate your Assembly folder and drill down to the DLL. This is where the
GAC is really storing your DLL. Copy the PDB file from your VS.NET
projects \bin\debug subdirectory each time you recompile your assembly
(I typically use an XCOPY in the Post Build Events). You will also have
to recycle the AppPool each time you recompile because the .NET
Framework is actually running a shadow copy of your DLL and the recycle
will flush the cache. I use this command, also in the Post Build Events,
to recycle the AppPool:

%systemroot%\system32\iisapp.vbs /a "SharePointAppPool" /r

where SharePointAppPool is the name of the AppPool that your Web
Application is using. If that doesn't work, you can always run an
iisreset; it just takes longer.

With the right Post Build Events in place (GacUtil for DLL, XCopy for
PDB, and the AppPool recycle) I use a systematic approach each time
(presumes that you already have a break point set): Change code, rebuild
(not just build), refresh in the browser, attach to the W3WP process,
refresh in the browser again to hit your break point. While the first
refresh in the browser isn't required, I find that things don't get out
of sync as often using these steps.

Now you should be able to debug your assembly while it is still in the
GAC.

That appears to have worked. I just need to make sure I pick the
right app pool.

Thanks for your help. Be sure to say Hi to Brian Findlay and Greg
Lynn when they attend your summit in Atlanta next week. Their from my
web shop.

I'm an Aug 07 DC alum.

This will be my second trip to Alpharetta (AT&T land now, rather than
Cingular); I remember cause it is so dog-gone far from the airport. Last
time I barely made it to the airport for my flight home on Friday night.

I'll give special notice to Brian and Greg next week. Probably tell them
that Randall said to grill 'em real good.

Are you writing your own web  service? Or trying to debug inside one of
the built-in webservices? If it's the later you won't be able to
because you don't have the Microsoft source code and the deployed DLL
doesn't include the debug bits.

If its your own you should be able to just pull the web service  up in
VS2005, attach to the W3WP.exe process, and set a breakpoint.

It's a custom web  service project.

I have a class library project that represents my DLL and my asmx file
just points to it. When I attach to a process, it never reaches the
breakpoints in my dll code. I just get the web service  SoapException
in my web service consuming project.

The problem is that your program isn't finding the .PDB file which
contains the debugging  symbols. To do that for a file that is deployed
to the GAC you should add the location of your webservice output
directory to Tools>Options>Debugging>Symbols in your VS 2005 web  service
project. That will allow the project to pick up the symbols to debug
the .DLL that is stored in the GAC.