This project is read-only.
This is a handy Visual Studio add-in that will save you time by automating the SharePoint (or any other server-side code running under IIS hood) debugging.


The component comes under MS-PL license. We request no license fees or donations. We prefer you pay back by tweeting about this tool.

All money collected by commercials or banners is decided to be donated to charities.

What's new

Any development on version 2.4 is been discontinued.

Version 3.1.1
  1. Sandboxed code support.
  2. Bug fixes.
  3. UI improvements.
Version 3.0
  1. Major UI facelift.
  2. Performance improvements.
  3. Visual Studio 2012 Light/Dark Theme support.
  4. Visual Studio 2013 Light/Dark/Blue Theme support.
window3-80.png window5-80.png

All icons belong to Icon8 set from VisualPharm

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.


For an even more enhanced SharePoint debugging experience, combine Visual Studio SharePoint Debugging Assistant with our other tool Visual Studio Integrated ULS Viewer :


Last edited Sep 29, 2014 at 5:58 PM by akyriako, version 41