views:

828

answers:

5

How do you debug your SharePoint 2007 code? Since SharePoint runs on a remote server, and I'm developing on a windows xp machine (with the necessary .dll files copied into my GAC), I haven't had much luck with finding easy ways to debug. Breakpoints don't work, etc.

The best way I've come up with is to enable page tracing in the web.config file, write trace messages throughout my code, and access trace.axd whenever I need to debug.

Does anyone have any better suggestions for debugging? Am I missing something?

+3  A: 

From Andrew Connell's blog post on the subject:

Attaching the debugger to GAC'd assemblies: "Why aren't my breakpoints being hit?!?!" Ever been there? Me too... what a PITA that is! What's going on? Well, the assemblies are in the GAC and the Visual Studio debugger can't see the debugging symbols (aka: *.pdb). Unless you've gone through the trouble of setting up a symbol store where all your PDBs are going, you'll need to put the debugging symbols in the same location as the assembly. The trick is finding the folder that contains your DLL in the GAC.

The c:\windows\assembly folder is not a real folder, it's a virtual folder. To get to the REAL folder, do the following:

  • Start » Run
  • %systemroot%\assembly\gac [ENTER]

This will open the GAC folder. Now, poke around until you find a folder that looks like this (you might need to jump up one folder and dive into the MSIL folder): [assembly file name -.DLL extention][assembly version in format of > #.#.#.#][assembly public key token].**

When you find that folder, open it up and you'll see your assembly. Copy the PDB file to that folder and then attach the debugger for some debugging joy!

Mitch Wheat
You can also debug on assemblies in the GAC of a remote machine when you connect to a process as long as that PDB is in the output directory on your local machine of the current project. I debug on MOSS assemblies in the GAC on remote machines all the time without copying the PDB into the GAC.
spoon16
+1  A: 

I recommend you develop on a Windows 2003 server with Sharepoint. It's a hassle to debug on a remote server. You can do it in a virtual machine with VMWare or Virtual PC, if you have XP on your workstation.

JacquesB
+1  A: 

Virtual machine is the only way to go. You don't want to dedicate a whole machine to dev (unless you have extras) and developing on your production server is just asking for trouble. I prefer VMWare, but there are others that work just as well.

Tracing works well as normal debugging isn't really an option.

What else I do is try to develop all the logic (the stuff that isn't SharePoint dependent) on just a regular asp.net site, then integrate it into SharePoint after it's tested.

Hope that makes sense.

Are you talking about developing web parts? Custom pages? Something else?

naspinski
Erm - using VM's is not relevant to the orig question (although they are very very useful)
Ryan
Why is normal debugging not really an option? I seem to do it quite well all the time :)
spoon16
I know, I just thought I would throw that in there. I was explaining that I try to do my debugging in my normal non-SharePoint environment first (Visual Studio) as debugging the in SP environment is difficult.
naspinski
+2  A: 

The best way (even the one endorsed by Microsoft) is to have a Windows 2003 Server with Sharepoint as your local Development machine.

See also this topic.

Michael Stum
+2  A: 

Don't put your assemblies into the GAC, put them in the bin directory - then you can use the VS remote debugger. Google creating .WSP files for distribution.

This also has the advantage that its easier to copy your new builds onto the server after compilation (post-build step) and its also the recommended way to increase security.

Ryan
Sometimes not-gac'g an assembly isn't much of an option. Especially when you're talking about having to rework your WSP and redeploy. this can be a painful process if you're just trying to debug a one-off error that you can't find any other way (a problem I'm currently having).
MBonig