Plugin registration tool throwing Unable to load plug-in assembly

Question

I'm using the latest version of the MS CRM 2011 SDK and am trying to deploy a custom workflow activity (it has been signed with a key). The plugin registration tool throws an error "Unable to load plug-in assembly" without much information about the root cause. The error trace thrown by the tool is very similar to the one described in this post

The answer to the post referenced above indicates adding Microsoft.Xrm.Client assembly in the GAC, but my workflow project references the following DLLs 1)Microsoft.Crm.Sdk.Proxy.dll 2)Microsoft.Xrm.Sdk.dll 3)Microsoft.Xrm.Client.dll 4)Microsoft.Xrm.Sdk.Workflow.dll

Should all these be added to the GAC? The CRM server is Win 2K8R2. I tried dragging and dropping the assemblies to the c:\windows\assembly folder but that did not work. No errors but nothing was copied over either. I followed the instructions outlined in this post but that did not work either.

What am I missing?

Answer 1

I don't think you should have to place any crm dlls into the gac, they are already installed in the CRM server files. If you think it might solve the problem use gacutil (not clear if you can't install to the gac, or if that didn't fix the problem).

I suspect its complaining about your dll, are you trying to register to the disk? As you usually have to place the dll in the crm/server/bin folder first. Try deploying to the database - makes life easier for deploying the solution to other servers later.

If that still doesn't work post the trace of the error.

Answer 2

Turn on crm server side.tracing. You'll get much better error information. Use the CRM diagnostic tool to turn on trace logging: http://crmdiagtool2011.codeplex.com

Answer 3

Turns out that if you use the /codecustomization switch to have the code generator derive from "CrmOrganizationcContext", you need "microsoft.xrm.client.dll". This DLL is not included in the default install of CRM and you need to get this on the server one wa or another. I decided against using the /codecustomization switch which causes the "context" to derive from "OrganizationContext" instead and not take a dependency on that DLL. Plugin registration now works! This post provides more insight