Debugging sandboxed plugins

Microsoft Dynamics CRM 2011 includes a feature to allow sandboxing of plugins. This means that the program execution is fenced off from the rest of the server to avoid any buggs or exploit attempts in the plugins to affect the rest of the server. This is most useful in the CRM Online and partner hosted deployments but can also be used in normal on-premise solutions to fence off some risky code.

When developing plugins, I strongly recommend a local CRM installation, even if the deployment of the plugin is going to be on CRM Online. It is not possible to step-debug programs on CRM online for natural reasons, and the shotgun-debugging approach that is available from the CRM Plugin SDK is quite rough and does increase development time.

Normally when step-debugging plugins, you would attach to the w3wp process for the CRM app-pool.

However, you do have to remember that plugins that are registered to be run in the sandbox, actually are executed under a different process hence you cannot attach to the w3wp process when debugging but instead have to attach to the Sandbox process.

If you would like, it is also possible to register the plugin outside the sandbox first while developing and the re-register it in the sandbox later. Some errors might, however, only show when working with sandboxed plugins so it is also good to be able to debug these.

Do note that it I have installed the sandbox to use Network Servce as the executing account, this is not recommended for production deployments, since that will nullify some of the security features of the sandbox. Instead a dedicated minimum security account should be used to block the process from accessing anything outside the sandbox.

Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB

www.crmkonsulterna.se