SharePoint Debugging Assistant (free Visual Studio 2012/2013 add-in)

Project Description
SharePoint Debugging Assistant is free of charge Visual Studio add-in that will save you time by automating the SharePoint (or any other server-side code running under IIS hood) debugging.

Debugging SharePoint SOM code by attaching to the corresponding IIS process can become a tedious, frustrating and time consuming activity for every developer. It requires a 3 steps procedure that in the end might leave you with an aftertaste of uncertainty :

  1. Debug Menu -> Attach to Process…
  2. Select “Show processes from all users” in case you develop following a Medium/High Security Option paradigm in your SharePoint development environment (you SHOULD!!!).
  3. Select the “correct” w3wp.exe process that your web application runs under (????).

As you can notice in the picture we face the following inconveniences :


  • w3wp.exe has no “Title” to indicate user friendly information.
  • w3wp.exe’s “ID” is an arbitrary integer value assigned by IIS upon creation and every time an application pool has been recycled is automatically renewed.

So which is your target process ?

Workaround : Many developers just for brevity choose attaching to all available w3wp.exe processes. This is where SharePoint Assistant applies :

Based on a pull model of interrogating directly the IIS metabase, SharePoint Assistant periodically or ad-hoc populates a list with all the active application pools of IIS and correlates them with the underlying w3wp.exe process. Within just a right-click developer is capable of recycling or attaching to any application pool of his interest utilizing directly the generic Visual Studio debugging engine and the IIS metabase.


SharePoint Assistant was conceptualized and developed in order to bring a holistic one-stop experience for the web developer, integrated in his natural habitat : Visual Studio. So attaching to and debugging a w3wp.exe process (IIS working process) is simply not enough for a SharePoint developer. A lot of artifacts are running under certain local Windows Services (TimerJobs, Workflows SP14) or in separate new systems under the hood of a discrete processes (Workflows SP15).

SharePoint Assistant is aggregating vital signs (pull model) from the necessary processes and visualizes them via traffic light indicators so the developer is aware at any given moment of the operational status of his box :

  1. IIS : Developer can reset the application server on demand.
  2. SharePoint Timer Service : The Windows Service responsible,among others, for the execution of timer jobs and workflows (WF3 in SharePoint 2010/2013). Possible to Attach and Restart.
  3. Workflow Manager 1.x Processes : The Windows Processes that Workflow Manager 1.x is running under (WF4, SharePoint 2013). Possible only to Attach.