I learned some interesting things about working with Sandboxed plugins last week that I thought I’d share.
Attaching to Processes
Sandboxed plugins are run by Microsoft.Crm.Sandbox.WorkerProcess.exe so that is the process that you will need to attach to in order to debug your plugin. If there are more than one, then attach to all of them.
If there are none active in memory, perform whatever process that activates your plugin and the Sandbox HostService will activate at least one. Then you can attach to them.
If you are running a sandboxed plugin with an asynchronous step, you will also need to attach to CrmAsyncService.exe since this process is involved as well. More on that in a minute.
Using the Debugger
The Sandbox HostService only allows the WorkerProcess to process for 30 seconds. If it runs longer, it is terminated. This is a real problem when you’re trying to look at data within the debugger and your code and data disappears in front of your eyes.
Add a DWORD key called SandboxDebugPlugins with a value of 1 to the MSCRM registry to prevent the process from being abnormally terminated.
Asynchronous Plugin Steps
A very interesting factoid is that if you have an asynchronous step inside of the sandbox plug, the processing of the step is different:
The CrmAsyncService.exe process will run your asynchronous step as it would any other async process but since it is from a sandboxed plugin, it will actually hand your plugin to the Sandbox process for execution.
This is why you must attach to both the Microsoft.Crm.Sandbox.WorkerProcess.exe and CrmAsyncService.exe in order to get the Visual Studio debugger to launch.
More Information
See this topic in the CRM SDK for more information.
