I'm currently using a Virtual PC at work that is acting as a Windows SharePoint Services (WSS) server, but it's not (and can't be) joined to the same domain that my dev workstation is on. This obviously creates a problem for debugging web parts on the virtual PC (remote debugging just won't work), and there's no way I'm going to rely on Response.Write() to output exception details while developing.
So, Dan suggested a few ideas to try to make this a little less painful. Read the prerequisite on Debugging Web Parts first, then read on:
- Install the .Net SDK on the virtual PC.
- Drop the web part DLL and PDB file into the virtual PC's Global Assembly Cache (GAC)
- On the virtual PC, open GuiDebug from the .Net SDK, and attach to the W3WP process
- Open your web part source file (either a .cs or .vb file), set breakpoints, and debug until you can't debug no mo'.
The down side is that both the web part DLL and PDB must be in the GAC for this to work. Putting the DLL in the WSS site's bin folder, or putting only the DLL in the GAC will result in debug symbols not being loaded in GuiDebug. To make matters more complicated, you can't drag-and-drop PDB files into the GAC. Instead, you'll need to copy them using a command prompt. Dan recommended setting up a BAT file to take care of this since the DLL and PDB files will likely need to be copied multiple times during the debugging process.
Unless you can debug locally (read: you have Windows 2003 Server installed locally), this will probably be your best option.