I no longer work at Microsoft, so please don't bother leaving a comment here or trying to contact me through my MSDN blog.
You can find my new blog at http://www.technologytoolbox.com/blog/jjameson. My new site also provides copies of all posts from my MSDN blog.
In yesterday's post, I provided a sample walkthrough of the "DR.DADA" approach to developing solutions for Microsoft Office SharePoint Server (MOSS) 2007. However, I intentionally left out a few things because a) that post was already getting ridiculously long, and b) I felt these were important enough to cover separately.
One of the incorrect statements I've heard a few times over the last couple of years is that you can't do "F5 debugging" when working with SharePoint. Well, I suppose that in the strictest sense, this is a true statement -- assuming you don't go crazy with post-build events (for example, to deploy your updated WSP, re-GAC your assemblies, and recycle the application pool). Instead, most developers -- including myself back in the early days of MOSS 2007 -- start debugging by attaching to the IIS worker process (i.e. w3wp.exe).
However, when you have multiple instances of w3wp.exe (for example you are running a couple of SharePoint Web applications in addition to Central Administration) it can be tedious attaching to the right worker process. [In other words, the old keystroke combination many of us grew accustomed to back in the days of working on a single ASP.NET Web appliction -- specifically, pressing CTRL+SHIFT+P (to bring up the Attach To Process dialog box), pressing W (to scroll the list of processes down to w3wp.exe), followed by two quick presses of the Enter key -- doesn't work anymore because we might attach to the wrong worker process. Even worse, we might not be able to quickly tell which w3wp.exe instance to attach to without expanding the User Name column -- or even worse still, having to use iisapp.vbs (in Windows Server 2003) or C:\Windows\System32\inetsrv\appcmd.exe list apppool (in Windows Server 2008) to determine which process to attach to.]
Don't fret...attaching to the right worker process to debug your SharePoint code can be very easy.
Suppose you've created a Class Library project in Visual Studio for your feature, which includes things like a master page with code-behind, custom Web Parts, event receivers, or perhaps even a feature receiver or two -- and now you actually need to debug that code. [Note that there's actually a much easier way to debug your feature receivers, but for the purposes of this post, suppose you actually want to debug activating a feature through Site Settings.]
First, you need to "Web-enable" your class library project. [I'm not sure if "Web-enabling" is actually the official name for this -- in fact, I doubt it. However, that's what I've been calling it for a few years now and it seems to describe the concept to most people I tell this to.]
Unfortunately, there's no user interface in Visual Studio 2008 for "Web-enabling" your project so you have to modify the MSBuild project file directly.
To Web-enable your C# class library project and configure for ASP.NET debugging:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition="" />
In addition to seeing the Web tab in project settings, you will also find that adding items like ASPX pages and ASCX controls is much easier after "Web-enabing" your project.
To ensure ASP.NET debugging is enabled on the Web site [note these instructions are for Windows Server 2008]:
Assuming you have deployed your solution and activated your features, your can now set a breakpoint and press F5 to start debugging. Woohoo!
Now let's suppose that you find a bug in your code and need to make a change -- but only to the code. In other words, you haven't modified any of your files deployed to %ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\12.
As I mentioned yesterday, all you need to do is press CTRL+SHIFT+B to build your solution, GAC your updated assemblies, and recycle the application pool:
Installing assembly: Fabrikam.Demo.CoreServices.dll (Debug)
Assembly successfully added to the cache
Installing assembly: Fabrikam.Demo.Publishing.dll (Debug)
Assembly successfully added to the cache
C:\NotBackedUp\Fabrikam\Demo\Main\Source\Publishing\DeploymentFiles\Scripts>C:\Windows\System32\inetsrv\appcmd.exe recycle apppool "SharePoint - foobar-local80"
"SharePoint - foobar-local80" successfully recycled
You can then simply press F5 to start debugging again. Woohoo, indeed!
I hope this makes you a happier and more productive SharePoint developer.