I have written posts on how to debug with the Plugin Registration Tool (PRT) and the PRT features in the past.
Working mainly with Online deployments lately, I gathered some insights I would like to share here.
First, some facts:
- Debugging Online deployed Custom Workflow Activities (CWA) with the PRT is currently impossible
This is sad, because there is no method to debug Online CWA with Visual Studio. The PRT is certainly purposed to help debugging CWA, but the functionality just doesn’t work.
Additionally, current (v7.1.1) and former SDK versions do not describe CWA debugging procedure with the PRT, only the Plugin debugging procedure.
I have approached MSCRM SDK team regarding these problems a few months ago and notified these issues will be addressed in future SDK versions.
Until that happens, I develop and debug CWA in an on premise organization and then publish to the target Online organization. - The PRT is the only option to debug Online deployed Plugin components with Visual Studio debugger
Microsoft Online deployments do not expose server processes, so VS Attach to Server Process technique is not viable.
The fact that the PRT is an only option doesn’t mean it is a bad option. Actually, I find it superior to the Attach to Server Process technique in all aspects when it comes to debugging Plugin components, even in an on premise deployment. Read on to find out why. - Debugging CWA/Plugin components in on premise production deployment with Attach to Server Process technique is usually not viable
Similarly to Online deployment, on premise production deployment do not expose server processes as this is considered a security breach.
So in this scenario, the PRT is again the only option to debug CWA/Plugin components with the Visual Studio debugger.
Now, let’s compere PRT with the Attach to Server Process technique, which is the common alternative technique to debug Plugin/CWA components with VS:
- Server Process Blocking:
Debugging synchronous components is usually performed by attaching the Visual Studio debugger to the W3WP server process, which blocks the process. It means that while you are busy debugging, the entire application is unresponsive for any other users (developers, QA testers etc.). If you are working alone there is no problem but when other users are involved, this seriously affect their productivity, not to mention deeply annoying them. It also means other developers can’t debug synchronous components while you do.With the PRT technique, you attach the Visual Studio debugger to the PRT process, which runs on your dev machine. This means no server process is blocked while you debug and no one is planning to assassinate you.
- DLL updating while debugging:
While debugging with the Attach to Server Process technique, each code edit & compilation cycle requires updating the Plugin/CWA DLL on the server. While this process involves only a few mouse clicks, when done over and over again (common in debugging scenarios) it becomes a real time consumer and also takes your mental focus off the actual debugging process. Add to this the need to trigger the Plugin/CWA execution by using MSCRM UI (e.g. create or update a record) for each debugging cycle and watch your productivity rate flatline.With the PRT technique there is no need to deploy the DLL while debugging, as the PRT process is mapped to the DLL in your project BIN directory.
No need to execute any UI triggering process since the context is packaged in the PRT debugging Profile.
This is a MAJOR time saver. - Replay debugging scenario:
The PRT has the magical Replay feature which the Attach to Server Process technique lacks.
This feature allows you debug Production and inaccessible MSCRM deployments since the debugging context can be extracted (by system administrator) as a text file and used with the PRT on your dev machine assuming you have the relevant DLL.
Off course, SDK calls in your code will not be executed in this scenario, but in many cases the debugging context is enough to trace the culprit.
Finally, I recommend using the ReAttach extension for Visual Studio coupled with the PRT to maximize the debugging process efficiency.