Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
Plugins in CRM are great ways to run powerful .NET code and our one of the CRM Developers most powerful tools in his toolbox.
There are lots of steps you need to go through when creating a plugin and there are lots of things which can error.
The knowledge you need is usually built up with a bit of theoretical knowledge and then a lot of practical trying. The amount of knowledge you need to write a plugin is one of the reasons Why .NET developers struggle with CRM Development
If you are starting out writing plugins, I would recommend my youtube plugin playlist
I would recommend reading my blog post on common plugin errors, which you will certainly experience at some point CRM 2011/2013 – Common Plugin Errors and Isolation Mode
The common errors talks about the post discusses a deployment common error you might experience, which is you cannot deploy plugins with isolation mode = none if you are not a deployment administrator.
If the isolation mode = “Sandbox” then any CRM Developer who has the security role of Administrator can deploy plugins into a sandboxed environment.
When you create a plugin you can choose two different types of isolation mode
You may have seen these when you are deploying plugins in the CRM Developer toolkit, it’s in the RegisterFile.crmregister file, you can see each assembly has
You can also see what isolation mode of a plugin if you open the Plugin Registration Tool.
When developers talk, naming and terms used can add confusion and slow down people’s understanding.
A plugin assembly has a setting called Isolation mode and this can be set to None or Sandboxed, but you will rarely hear any CRM developers use the term isolation mode.
Instead they will say things like these
When a CRM Developer mention Sandbox/Sandboxed and plugin they mean the plugin has an isolation mode which equal “Sandbox”
CRM online plugins can only run with an isolation mode = sandboxed
A normal plugin is a plugin which has an isolation mode = “none”
CRM isolation mode is used all the time by all CRM developers who create plugins but often most CRM developers only have a vague idea of what Isolation mode means.
Most CRM Developers will have heard about Isolation mode with regards to CRM online. The reason for this is CRM Plugins created for CRM Online organisations must have Isolation mode = “Sandboxed”
The first (and best) place to start with understanding Isolation mode and Sandboxed plugins is with this great MSDN article which can be found in the CRM SDK (which should be the first place you look for documentation)
Plug-in isolation, trusts, and statistics
You will notice the isolation mode of a plugin is at the assembly level and not the individual plugin level.
This is why when you create a new plugin there is no setting for isolation mode because it’s at a DLL\project level and you can have many plugins inside one project (or inside one dll).
Plugins with an isolation level of “Sandbox” run in an isolated environment and as you can imagine this environment is more secure. Key point
The sandbox is more secure and some actions are restricted
The restrictions are a bit of mystery, in the sense there is not one all encompassing list of code which will cause an error in a sandboxed plugin. This can be very frustrating when you deploy a plugin in the sandbox and it throws an error, finding the cause of this can be difficult and frustrating.
The Plug-in isolation, trusts, and statistics article states
isolated environment, also known as a sandbox, a plug-in or custom activity can make use of the full power of the Microsoft Dynamics CRM SDK to access the organization web service. Access to the file system, system event log, certain network protocols, registry, and more is prevented in the sandbox.
The article gives a good description of what this means by saying Plugins deployed in the sandbox are partially trusted (e.g. you only partially trust the plugin and are limiting it’s powers) and plugins which are not in the sandboxed are fully trusted (by you the developer) and you are happy to let them interact with the file system, registry, call other dll’s and web services etc.
I recently had some experience with sandboxed plugins because a project I was working on moved all the plugins out of the sandbox. The first result was I couldn’t not update or publish any plugins because I wasn’t a Deployment admin
The second side effect is I remember the sandbox has its own service. If you have ever installed CRM you notice there are Sandbox CRM Service and standard CRM Service. Most CRM Developers know of the services when they do one of the many IISRESETS + Service restart, which usually happens if you have DLL’s in the GAC. The sandbox service runs all the sandbox plugins.
The sandbox service runs all the sandbox plugins.
I was remote debugging, so instead of attaching the remote debugging to the
One reason I personally don’t like remote debugging is if someone is debugging a standard plugin, then by debugging the w3wp they stop the whole server whilst and everyone else who is using it. I have seen some scenarios where other developers and testers have had to stop whilst the one developer debugged his plugin (poor show).
To get around this you can change the plugin to sandboxed and then when you debug you only stop the sandbox service
I have stated previously it’s difficult to know what the limitations are but here some of the limitations taken from the msdn article
This blog had some good restrictions in a bit more detail
I believe CRM online sandboxed plugins cannot use LINQ queries, which throws an error due to another transaction being created in the LINQ query.
Custom workflows cannot be used in the CRM online sandbox
I came across an error which prompted me to write this blog post. I was trying to searilze some fields and pass them between plugins using shared variables
This forum post below is the same error
This error was unusual because it was complaining about access to a critical method. I wondered why serialization was critical method but thinking about it, serialization must involve writing the data to disk and sandboxed plugins are not allowed to do this.
A Gotcha also occurred when someone changed the plugin to sandbox mode, it stopped the plugin working, so I had to leave a comment in the code to say, this plugin won’t work if the plugin is sandboxed.
So the question is why would people choose to put plugins in the sandbox.
The most common reason is they are using CRM online and you have no choice because all plugins have to be
Runtime statistics are created PluginTypeStatistic entity records. These records are populated within 30 minutes to one hour after the sandboxed custom code executes
This url has an interesting benefit
Some readers maybe dissapointed I haven’t listed all the methods and exact lines of code which will cause sandbox plugins to throw security errors.
Whilst writing this blog post I realised the reason Microsoft have listed all the causes of security errors in sandboxed plugins because there are potentially lots of them and if they tried to list them all, they would miss some. In fact I would say it’s impossible to list them all, so there is no benefit to trying.
The way to think about the sandbox is it’s a bit like a sandpit and the code is a child. As soon as any code/child tries to get out of the sandpit we throw an error and a parent comes along, tells the child off and throws them back in the sandpit.
This is why sandboxed code is safer because it can’t get onto your server and cause havoc.
The limitations of sandboxed plugins can be a significant influencing factor for many CRM solutions to be on premise.
The limitation of not being able to call webservices and DLL’s in the GAC can be quite restrictive.
There is a solution using ILMERGE, which is a method of merging a number of different DLL’s into one DLL, which will allow you to use the plugin in a sandboxed environment. I would be cautious about this approach because if you ask anyone who has done it, they will tell you it wasn’t easy and debugging a merged DLL can be impossible.
Here is a good article on ILMerge issues
Business Applications communities