Debugging SharePoint 2007 Code

Question

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?

Answer 1

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!

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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?