调试SharePoint服务器管理对象(SOM)代码，通过附加到对应的IIS进程，对于每个开发者来说，可能是一项繁琐、令人沮丧且耗时的活动。这个过程需要三个步骤，最终可能会让感到不确定： 调试菜单 -> 附加到进程... 如果遵循中/高安全选项范式进行SharePoint开发环境的开发（应该这么做！），则选择“显示所有用户的进程”。 选择Web应用程序运行的“正确”的w3wp.exe进程（？？？）。 正如在图片中所看到的，面临以下不便： w3wp.exe没有“标题”来提供用户友好的信息。 w3wp.exe的“ID”是IIS在创建时分配的一个任意整数值，每次应用程序池被回收时都会自动更新。 那么，目标进程是哪个呢？
解决方案：许多开发者为了简洁起见，选择附加到所有可用的w3wp.exe进程。这就是SharePoint助手的用武之地： SharePoint助手基于直接查询IIS元数据库的拉取模型，定期或临时填充一个包含所有活动应用程序池的IIS列表，并将其与底层的w3wp.exe进程相关联。开发者只需右键点击，就可以利用通用的Visual Studio调试引擎和IIS元数据库，直接回收或附加到他感兴趣的任何应用程序池。
SharePoint助手是为了给Web开发者提供一个全面的一站式体验而构思和开发的，集成在他的自然栖息地：Visual Studio中。因此，对于SharePoint开发者来说，仅仅附加到并调试一个w3wp.exe进程（IIS工作进程）是不够的。许多工件在某些本地Windows服务（定时作业，工作流SP14）下运行，或者在单独的新系统下运行，这些系统在不同的进程下运行（工作流SP15）。 SharePoint助手通过拉取模型聚合必要的进程的重要信号，并通过交通灯指示器可视化它们，以便开发者在任何给定时刻都能了解他的盒子的运行状态： IIS：开发者可以根据需要重置应用程序服务器。 SharePoint定时服务：负责执行定时作业和工作流（WF3在SharePoint 2010/2013中）的Windows服务。可以附加和重启。 工作流管理器1.x进程：工作流管理器1.x运行的Windows进程（WF4，SharePoint 2013）。只能附加。
它会降低Visual Studio性能吗？ 当然不会。它是通过Visual Studio扩展SDK构建的，所有对WMI、服务、进程和IIS元数据库的外部调用都是通过.NET 4.5的最新异步/等待模型作为后台操作完成的，并且完全不干扰Visual Studio线程。
它只适用于SharePoint吗？ 当然不是。可以调试任何在IIS应用程序池中执行的应用程序。例如：ASP.NET（表单、页面、MVC）、Web服务、WCF服务等，只要它与服务器端托管代码有关。