Random Musings of Jeremy Jameson : Debugging

"Web-Enabled" Projects and F5 Debugging with SharePoint

Jeremy Jameson — Tue, 29 Sep 2009 17:07:00 GMT

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:

In the Solution Explorer window, select the class library project.
Right-click the project name and then click Unload Project.
Right-click the unloaded project and then click Edit {project name}.
Below the <ProjectGuid> element, add the following:

<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
Below the <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> element, add the following:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition="" />
On the File menu, click Close. When prompted to save the file, click Yes.
In the Solution Explorer window, right-click the project, and then click Reload Project.
Wait for the project to finish loading, right-click the project name again, and click Properties. Notice that there is now a Web tab in the project settings.
On the project settings Web tab, under the Servers section:
1. Clear the Apply server settings to all users (store in project file) checkbox (since various members of the Development team might use different URLs for their local SharePoint sites).
2. Select the Use Custom Web Server option, and in the Server Url box, type the URL of your SharePoint site (e.g. http://fabweb-local).
Close the project settings window.
In the Solution Explorer window, right-click the project, and then click Set as StartUp Project.

Note

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]:

Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.
In the Connections pane, expand the computer name.
Expand Sites.
Select the Web site or application that you want to debug.
Under the ASP.NET section, double-click .NET Compilation.
Under the Behavior section, ensure the value of Debug is set to True.
If necessary, click Apply in the Actions pane.

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:

C:\NotBackedUp\Fabrikam\Demo\Main\Source\Publishing\DeploymentFiles\Scripts>"GAC Assemblies.cmd"
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
Done
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.

Debugging Symbols -- They're Not Just for Debug Builds Anymore

Jeremy Jameson — Sat, 26 Sep 2009 16:20:00 GMT

I started another new project this week.

Typically one of the first tasks on any new development project is to create a Development Plan that provides consistent guidelines and processes for the Development team. On this new project, another Microsoft consultant had already created a draft of the Development Plan, but in the process of reviewing it, I added some content from a Development Plan that I had created a few years ago.

In the process of reviewing my old document, I came across the following:

Installation
...
Debug Symbols

All Debug builds should create symbol files for debugging purposes. These symbols are included as part of the setup to facilitate debugging in other environments such as DEV.

Important

Do not include Debug symbols in the Release configuration of the setup projects.

When I read this, I actually let out an audible laugh (okay, I suppose it was more of a chuckle). It must have been the old C++ developer in me that originally put this in the Development Plan (thinking you should never provide PDB files in your Release builds because it makes it all too easy for an outsider to understand your code).

Well, any .NET developer who has ever fired up Reflector on somebody else's assembly (which hasn't been obfuscated, obviously) knows very well how easy it is to decompile -- er, I mean disassemble -- source code. In fact, regardless of whether you have the PDB files, you can actually debug .NET code -- including setting breakpoints and examining variables -- using tools like WinDbg. I've had to do a little of this in the past and while it's not exactly easy -- especially for a developer who doesn't use WinDbg frequently -- it does help out in a pinch when troubleshooting some nasty problem in Production.

However, including debugging symbols (i.e. PDB files) in Release builds certainly makes debugging .NET code easier. This is a key point that John Robbins makes in Debugging Microsoft .NET 2.0 Applications. In fact, here's a direct quote from page 38:

Build All Builds with Debugging Symbols
...build all builds, including release builds, with full debugging symbols. [...]

In other words, the Development Plan should say:

Important

Always include Debug symbols in the Release configuration of the setup projects -- or, preferably, make them available from a symbol server.

Regarding John's book...I strongly recommend this book to anyone who considers himself or herself a "serious developer." It is chock full of great tips and recommendations for developing .NET solutions.

Fiddler + WPAD - VPN = SlowPerformance

Jeremy Jameson — Fri, 27 Jun 2008 19:57:00 GMT

I needed to look at some low-level HTTP traffic this morning, so I fired up Fiddler -- my tool of choice for this kind of thing. Unfortunately, I found that as soon as I enabled Fiddler, my browsing experience slowed to a crawl. Page requests that previously completed in 1-2 seconds were subsequently taking 30-40 seconds. Ugh!

Since I typically work inside a virtual machine running Windows Server 2003, I thought that maybe I was hitting a problem specific to Fiddler on Vista. I then did a quick Windows Live Search using the terms Fidder Vista slow and quickly found a couple of people -- apparently including Eric Lawrence, himself -- referring to disabling IPv6 within Fiddler when using Vista. I assumed that this must be the problem that I was encountering, but no matter what I tried (e.g. restarting Fiddler after disabling the option, repeatedly enabling and disabling IPv6, etc.) I couldn't get the performance to improve.

I then fired up Network Monitor 3.1 and performed a quick trace while I requested the page through Fiddler again. [By the way, I absolutely love the new filtering capabilities in NetMon 3.1 versus the old version. The interface is much more intuitive than the old 2.x version and it couldn't be any easier than right-clicking a frame in the capture and selecting Add Cell to Display Filter. NetMon Team, you guys rock! I haven't quite got around to downloading the 3.2 beta, but hopefully someday soon.]

Also note that I had to right-click Microsoft Network Monitor 3.1 and click Run as administrator in order to avoid the dreaded "Unknown Error" that occurs when no networks are detected to capture.

So, a couple of minutes later, sure enough, there it was right in my capture:

DNS: QueryId = 0x18FC, QUERY (Standard query), Query for wpad.northamerica.corp.microsoft.com of type Host Addr on class Internet

As soon as I saw the old "Web Proxy Auto Detect" I immediately became suspicious that this was the culprit. I then closed Fiddler and modified my Internet Explorer options to clear the Automatically detect settings checkbox.

Shazam! Problem solved.

Of course, had I actually been connected to CorpNet (which would have enabled DNS requests for "wpad.northamerica.corp.microsoft.com" to resolve), I suppose I wouldn't have encountered the problem in the first place.

Perhaps it is the fact that I am frequently connecting to different networks (e.g. wireless, VPN, etc.) -- whereas many others don't -- but I'd really like to think most people don't encounter little gotchas like this. The mere thought of having to guide my mother through capturing a NetMon trace is, quite frankly, horrifying ;-)