Coding Lifestyle

Remote Debugging SharePoint Webparts in Moss June 29, 2007

With SharePoint 2007 came a lot of new features, but little changed in the way we develop webparts.  When developing webparts for WSS v2 or Portal 2003 my typical setup was a VM with both SharePoint and Visual Studio 2003 installed on the server.  My code would be on my workstation and then run from the server via a network path (i.e. \\mymachine\dev\webpart\webpart.sln).  After a flurry of warnings the project will load and work fine.  To debug the webpart follow these steps:

·        Set your system environment PATH variable making gacutil and stsadm available from the command prompt

·        Install the webpart making the necessary SafeControl entry in the web.config and placing the webpart’s dwp file in the wpcatalog directory

·        In addition, set the following in web.config:

o       debug=”true”

o       customErrors mode=”RemoteOnly”

o        trust level=”WSS_Medium”

·        Set the VS build output directory to be one of the following:

o       the bin directory

o       A temp directory and then GAC it via a post-build event

§         gacutil /I $(TargetPath)

·        Follow with an iisreset or application pool recycle via a post-build event.

·        Enable ASP.NET debugging

·        Set the debugger to start-up the URL of the page the webpart is hosted on

Simple! 

Actually, other than the pain of needing to install Visual Studio on every VM image it’s not a bad way of developing.  The main downside is SCC is not integrated which means running the SourceSafe client to manage files.  It is a handy way to make rapid, frequent changes, rebuild, hit debug and your browser opens the relevant page with your webpart and bang!  You hit your breakpoint.

This also works with SharePoint 2007 and VS2005 with a caveat.  In VS2003 you set the debug mode to be URL and gave the page hosting the webpart.  This would attach the debugger to both IE and the relevant w3wp process.  In VS2005 you set the debug start action to be start browser with URL.  This attaches the debugger to IE but not w3wp.  You need to do an additional step of attaching w3wp via the Debug->Attach to Process dialog.

Before remotely debugging SharePoint I’d recommend testing remote debugging with a “Hello world” console program.  There are lots of little issues with remote debugging I’m not going to delve in to (permissions and such).  Assuming you can get that far on your own, read on.  To pull off remote debugging we need to follow all the steps above but in addition:

• Install the VS2005 remote debugger on your server
• Post-build events will work differently
  • Now that we are remote debugging, any post-build events will execute on our workstation and not the server.  This means, gacing the webpart, putting its pdb file in the right location, and recycling the app pool must be done on the server.  I suggest putting the necessary commands together in a batch file, which is what a post-build event is, and running this from the server
  • For those who are fans of automating this as much as possible you need to find a way to execute your batch file on the server but triggered from VS2005’s post-build event running on your machine (the client).  I’d suggest writing a simple client/server application using the System.Runtime.Remoting namespace to register a TCP channel and registering a well known service type which the client can obtain via Activator.GetObject() in order to execute the command remotely on the server.  This looks to be the business as a good example or Fergal Grime’s excellent book Microsoft .Net for Programmers has an example in Introduction to Remoting.
• Ensure pdb files are being outputted to the same location as the dll
  • I noticed when GACing I had to place the pdb file in the GAC with the dll.  This is different behaviour from VS2003 executing directly on the server.
• Similarly to VS2003, set debugging to start with URL and give it the page hosting the webpart.  This will start IIS and open the browser.
• Debug->Attach to Process to attach to IIS
  • Transport: Default
  • Qualifier: server name (this may update to user@machine)
  • Select w3wp.exe from the list of processes
    • W2003 SP1 and later: If you have more than one w3wp process to choose from use c:\windows\system32\iisapp to list the sites and app pools
  • Select Attach

In conclusion, if you can figure a way to execute the batch file to register the assemblies, place the pdb files, and iisreset/recycle app pools you are no worse off than debugging directly on the server.  In addition to saving VM space this allows you to work from your workstation with properly integrated SCC.  If you are a real glutton for punishment even attaching to the w3wp process on the server can be automated via a macro, VS add-in, or via COM:

     EnvDTE80.DTE2 dte2 = (EnvDTE80.DTE2)System.Runtime.InteropServices.Marshal.GetActiveObject(“VisualStudio.DTE.8.0”).

Good luck!