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.

About

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 step 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, the 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.

Is it going to degrade my Visual Studio performance?

Certainly not. It is built via the Visual Studio Extensions SDK and all external calls to WMI, Services, Processes and IIS metabase are done via the up-to-date async/await model of .NET 4.5, as background operations, and do not interfere at all with the Visual Studio thread.

Is it exclusively for SharePoint?

Certainly not. You can debug any application that executes in an IIS application pool. e.g.: ASP.NET (Forms, Pages, MVC) , Web Services, WCF Services, etc. as long as it has to do with Server-Side Managed Code.

I can see staff missing there, not?

1. Sandbox solutions are not supported yet.
2. As we said before, this is only for Server-Side Managed Code running under CLR.

What is planned for the next release?

1. Remote debugging