Today I was asked a question, why should one register a plugin assembly as Sandbox? Well, the obvious answer is if one is registering the plugin to MSCRM Online or planning to migrate to MSCRM Online. Another thing is also that since it’s running in isolation mode, if things go wrong, code goes into eternal loop, it won’t have too much effect on the entire server. But other than that, I have very little idea on what is going on, so I decided to find out.
So these are the reasons that one should register plugin assembly into Sandbox:
1. Using MSCRM Online or planning to migrate to MSCRM Online (supported on all MSCRM deployments)
2. It is a more secure environment. No access to file system, system event log, certain network protocols, registry and more.
3. Supports run-time monitoring and statistics reporting
4. If sandbox worker process that hosts a plugin exceeds threshold CPU/memory/handle limits or unresponsive, it will be killed by the platform. And because there is one worker process per organization, failures in one organization will not affect another organization.
This is a very interesting feature that I think will help CRM developers in developing a more robust and efficient plugins. The statistics information is contained in PluginTypeStatistic entity. This entity contained informations such as:
1. Execute Count
2. Crash Count/Percent
3. Crash Contribution Percent
4. Related Entities
Plugin in Sandbox can access the web/network but there are some restrictions:
1. Only HTTP and HTTPS protocols are allowed
2. Loopback (localhost) access is not allowed
3. IP addresses cannot be used.
4. No provision for user credentials.
However you can modify these restrictions by changing regex of the registry key
Cheers – Sy