views:

307

answers:

4

Hi all

My OS is 64bit Server 2008, 64bit SharePoint2007 SP2, Visual Studio 2008 SP1.

I write a web part and deploy it to the server, it works fine, but I still want to debug it. I find the w3wp.exe's process ID(port 80), then I attach it to the Visual Studio as I do on the server 2003, but it seems do not work. But I make some breakpoints at the button event of this web part, after I attach it to the VS and click the button, it could not stop at the breakpoint. Does any one meet this problem before.

Best Regards,

+1  A: 

Some suggestions:

  1. Make sure you have recycled the application pool before attaching to the w3wp process.
  2. Build in Debug mode, ensure .pdb files are generated.
  3. Attach to the correct w3wp process. If you don't know, you could (but not recommended) attach to all w3wp's. Usually it would be the one used by the application pool account.
Floetic
A: 

And make sure that if your dll's are in the GAC, the pdb's are there too (copy .pdb to c:\windows\assenbly\GAC\GAC_MSIL\ASSEMBLYNAME\ASSEMBLYVERSION).

Somehow when I deploy a solution from Visual Studio using a script Visaul Studio will know which DLL's to use, if I create a solution and use the command line from the prompt it will not find the pdb's.

Colin
You don't need to copy PDB files to GAC. It's simple enought to leave them at build target location as visual studio will search that place for PDB also. I`v got more problems copying PDB's to GAC than leaving them where they are. Please read this - http://www.elumenotion.com/Blog/Lists/Posts/Post.aspx?ID=23
Janis Veinbergs
This somehow fails some of the time for me. Like I said, just after a build it'll be fine, but close visual studio, or log in / out and it won't work any more.. Maybe just me though...
Colin
+1  A: 

To expand on Brian's first point regarding recycling the application pool: The w3wp.exe process for that pool will not start up again until the first request to the site. If you attach before this you will attach to the wrong process (or there will be no w3wp.exe process at all). The cycle then is recycle, refresh, attach.

Here are some ways of making this easier (unfortunately no solution does everything):

  1. Use Application Pool Manager by Spence Harbar. This puts a little app in your Windows system tray that will recycle the app pool and warm it up again (meaning you don't need to refresh the page). You still need to attach the debugger.

  2. Use WSPBuilder and its built-in Visual Studio Extensions. This copies your files to the GAC and automatically recycles all application pools for you. You still need to refresh the page and attach a debugger.

  3. Use the Debugger Feature for SharePoint. This adds an entry to the Site Actions menu that attaches the debugger. It will attach to the correct w3wp.exe process and save you from doing the page refresh (as this happens as part of using the site actions menu). You will still need to recycle the application pool yourself as a first step. Also note that this is only useful for unhandled exceptions - it doesn't interact with Visual Studio so won't help in the breakpoint scenario.

Alex Angas
A: 

Another suggestion - after attaching to w3wp process (except if you debug timer job's - then attach to OWSTIMER.exe) press CTRL + ALT + U to see loaded modules and coresponding PDB files.

Right click on your DLL and view symbol load information - if it say's that PDB's don't match or something, just delete all PDB's from those locations you see in that window, rebuild project and try again.

Ah, yes, and you should read this.

Janis Veinbergs