Professional SharePoint® 2007 Web Content Management Development: Building Publishing Sites with Office SharePoint Server 2007

2.9. Debugging in WSS 3.0

One of the biggest differences between ASP.NET 2.0 development and SharePoint development is the debugging experience. When developing an ASP.NET 2.0 application, Visual Studio dramatically simplifies the debugging experience. Intuitive and straightforward, developers need only press the F5 key to automatically build the project and attach the debugger to the process hosting the ASP.NET 2.0 application. Unfortunately, the default experience in Visual Studio is not the same when developing SharePoint applications.

Visual Studio contains no special hooks into a SharePoint site. Thus, pressing F5 will result in an error because the application must be running within the process hosting the SharePoint application (the IIS application pool). The only time this isn't the case is when developing console or Windows Forms applications because they run within their own process.

So, how do developers debug assemblies designed to run within a SharePoint process, such as those containing Web Parts, custom field types and controls, event receivers, and workflows? The answer is to manually attach the debugger to the process hosting the application pool configured with the Web application that contains the target SharePoint site. The difference between this process and F5 debugging is that the developer has to perform the steps of attaching the debugger to the process manually; whereas with traditional ASP.NET 2.0 applications, pressing F5 performs the steps for the ...