- FileIOPermission - access the file system
- InteropPermission - mostly likely using an external assembly (either directly, or having ILMerged into your plugin assembly)
- System.Net.WebPermission - some for on network access, e.g. trying to access a network resource by IP address (the sandbox only allows by DNS name)
- SqlClientPermission - accessing SQL Server
- Execute code that doesn't try to access any local resources (file system, event log, threading etc)
- Call the CRM IOrganizationService using the context passed to the plugin
- Access remote web resources as long as you:
- Use http or https
- Use a domain name, not an IP address
- Do not use the .Net classes for authentication
So, what to do about it. If you have CRM OnPremise, the simple and only solution is to register the assembly outside the sandbox, so that it can run in FullTrust - i.e. do whatever it wants (though still subject to the permissions of the CRM service account or asynchronous service account that it runs under).
And if you've got CRM Online, then the normal solution is to offload the processing to an environment that you have more control over. The most common option is to offload the processing to Azure, using the Azure Service Bus or Azure Event Hub . The alternative, new to CRM 9, is to send the data to a WebHook, which can be hosted wherever you like.
Thanks for sharing the information i was looking for this.
ReplyDeletedynamics crm development
Hello,
ReplyDeleteI'm developing unit test library which simulates plugin execution in custom sandboxed AppDomain. Is anywhere available complete set of permissions which real sandbox process uses during loading plugin?
Thanks
Petr Jetel
Hello my family member! I wish to say that this post is amazing, nice written and come with approximately all important info's. I’d like to peer more posts like this.
ReplyDeletePDUSU BA 2nd Year Exam Result 2021