Registering plugin on disk has its benefits but can be tricky business. Plugin registration tool that comes with SDK is very coy about the errors and display the following message (in the log section of the form):
ERROR: Occurred while checking whether the assembly exists
You can opt to see more details about fault exception but it’s even less descriptive:
<InnerFault>
<ErrorCode>-2147204719</ErrorCode>
<ErrorDetails xmlns:a=”blah-blah-blah” />
<Message>Unable to load plug-in assembly.</Message>
- It’s non-intuitive (since you have to look up assembly on disk during the registration process!) but you already must have the assembly copied over into <CRMInstallation>\Server\bin\assembly folder on the server.
- Other reason is a bit trickier: CRMAppPool account must have at least read permissions on <CRMInstallation>\Server\bin\assembly folder. Normally everything is OK after the installation, but, after switching pool to another account (e.g. switching to domain account from NETWORK SERVICE for load balancing), folder permissions may go out of sync.
That wouldn’t have happened, of course, if you followed advice of Gonzalo “Comer mis pantalones cortos realizados en Canadá” Ruiz and registered your assembly in the database.
I wish I could buy you a beer. I’ve been trying to figure out why my plugin won’t register to disk for 2 days. It was reason #2.
Thank you for your kind words, appreciated – glad to help!
You can always buy us a beer at any of the Dynamics conferences: eXtremeCRM, CRMUG or Convergence.
“I wish I could buy you a beer.” Me too! haha