CRM 2011/2013 – Common Plugin Errors and Isolation Mode

I got this plugin error whilst trying to deploy my custom workflow

Error registering plugins and/or workflows. The resource string “ErrorSerializingRegFile” for the “RegisterPlugin” task cannot be found

I have had this error many times, so I thought I would go through the common plugin errors

 

Common plugin errors

Below is a list of the common plugin errors which can frustrate you for a while

 

Forgetting to sign the plugin

This is a common thing to forget.  If you plugin won’t register you need to sign the plugin, you can see steps how to do this on my blog post

CRM 2013 – Step by Step Update Plugin Tutorial using the CRM 2013 Development Toolkit

Solution – sign the plugin

 

Haven’t checked out the crmregister file

This error occurs if the crmregister file is set to read only

https://crmbusiness.wordpress.com/2014/01/22/crm-2011-error-registering-plugins-andor-workflows-the-resource-string-errorserializingregfile-for-the-registerplugin-task-cannot-be-found/

Solution – make the crmregister file read only or check it out of source control

 

Isolation Mode = “Sandbox”

You can also get errors if you haven’t set the isolation mode to the correct value.  Often this can be resolved by setting the isolation mode to none

CRM 2011 – plugins and isolation mode

Solution – change isolation mode = “none”

 

Error message “Assembly must be registered in isolation” when registering Plugins in Microsoft Dynamics CRM 2011

https://crmbusiness.wordpress.com/2012/04/20/crm-2011-assembly-must-be-registered-in-isolation/

Solution – Give the user Deployment Administrator role

 

Type Name incorrect

I added in my custom Workflow into my CRM Developer project.  It wrote a line to the RegisterFile.crmregister but

TypeName=”Maintenance.CWA.MaintenancePublish”

TypeName=”Hosk.Dynamics.Crm.Project.MaintenancePublish”

The CRM Developer toolkit didn’t put in the name space in front of the type.

Solution – Change the typename to include the namespace

 

Developer Toolkit

The CRM Developer toolkit is great and I love it, most of the time.  Sometimes I can get very frustrated with it, which you can read about here

What would be really good is if there was a way to regenerate the RegisterFile.crmregister from the plugins deployed in the CRM organisation.

I initially thought my problems were due to the CRM Developer toolkit getting itself into a pickle, but it turned out to be something more straight forward

 

Cannot register or unregister plugins!

The code I wrote was replacing a plugin with custom workflow.  The reasonfor this is by default plugins must run within 2 minutes or they time out.  The plugin was doing a lot of looping/recusive code, updating lots of related entities. This was causing an SQL timeout error.

To get round this I  created my custom workflow, the next step was to unregister the plugin but when I tried I got an error.

Not have enough privilege to complete Create operation for an SDK entity

 

Isolation mode

Earlier in the week the project had decided to change the plugins from

IsolationMode=”Sandbox”

to

IsolationMode=”None”

 

When you change this isolated setting to none this change the security privileges you need to deploy plugins.

Like most CRM problems the first place I search (and usually find answers) is the Hosk CRM blog

https://crmbusiness.wordpress.com/2012/04/20/crm-2011-assembly-must-be-registered-in-isolation/

 

The short answer is plugins with Isolation mode set to Sandbox can be registered by a user with the role of System Administrator.

Plugins with Isolation mode = “none” have to be a deployment administrator

Why X 5

Good CRM Developers are always asking why, 5 times according to wiki

http://en.wikipedia.org/wiki/5_Whys

 

Plugin Security Restrictions

There is a Microsoft a document/web page called

Register and Deploy Plug-Ins

No one ever reads this because it’s very long and detailed and you don’t need to understand all of it to create and register plugins (unless you have a problem of course).

Reading pages such as this one does help to increase your knowledge and understanding of how CRM works, which is why I am looking at it today.  I know there is a problem because I can’t undeploy my plugin or deploy my custom workflow but

 

WHY, WHY, WHY, WHY, WHY?

Below is the section called Security Restrictions

 

Security Restrictions

There is a security restriction that enables only privileged users to register plug-ins. For plug-ins that are not registered in isolation, the system user account under which the plug-in is being registered must exist in the Deployment Administrators group of Deployment Manager. Only the System Administrator user account or any user account included in the Deployment Administrators group can run Deployment Manager.

Important

For non-isolated plug-ins, failure to include the registering user account in the Deployment Administrators group results in an exception being thrown during plug-in registration. The exception description states “Not have enough privilege to complete Create operation for an SDK entity.”

The system user account under which the plug-in is being registered must have the following organization-wide security privileges:

• prvCreatePluginAssembly
• prvCreatePluginType
• prvCreateSdkMessageProcessingStep
• prvCreateSdkMessageProcessingStepImage
• prvCreateSdkMessageProcessingStepSecureConfig

Deployment Administrator

 

Deployment Administrator is a special role which can only be given out by a deployment administrator.  When you install CRM the account used to install CRM will be given the only deployment administrator role.  This user can open up the Deployment Manager application which is found on the CRM server.  Here the you can add more Deployment Administrators

If you want to learn more about Deployment Administrator role read the blog below

CRM 2011/2013 – Understanding and adding the deployment administrator role

 

Why am I talking about deployment administrators

In the security section above, there is this important paragraph.

For non-isolated plug-ins, failure to include the registering user account in the Deployment Administrators group results in an exception being thrown during plug-in registration. The exception description states “Not have enough privilege to complete Create operation for an SDK entity.”

Users are often set up as deployment administrators at the start of the project.  The reason this annoying popped up for me was because we had changed the isolation setting from Sandbox to none.

Before when I was publishing plugins with Isolation mode = “sandbox”, this paragraph was relevant.

For plug-ins registered in the sandbox (isolation mode), the system user account under which the plug-in is being registered must have the System Administrator role. Membership in the Deployment Administrators group is not required.

I added the deployment administrator role to my user and I was back publishing and unpublishing plugin.

Advertisement

CRM 2011 – in plugins only select the fields you need and not ColumnSet(true)

usually when I am first developing some code in a plugin I will select all columns in the query

e.g.

account Account= (account)service.Retrieve(account.EntityLogicalName, id, new ColumnSet(true));

Once I know the code is working I will change this to pass only retrieve the fields I need because this makes the code run quicker and it’s basically just lazy to select all the columns

I usually pass in a list

List<string> fields = new List<string> { “name”, “accountnumber”, “creditlimit” };

and set that to the columns.

 

Today I had to do this to fix a puzzling problem I was having.  My CRM was acting a bit wierd, I got a few timeouts when just viewing a custom entity form.  I couldn’t understand this at all because there wasn’t loads of field on the entity and there also wasn’t a lot of records so there was no reason I could the SQL should be running slow.

On the custom entity I did have a workflow which checked if certain fields changed and if they did it would set some fields on another entity.

I also had a plugin which was kicked off on the update event and in this plugin it was retrieving all the custom entity fields and then doing an update.

What was happening is I somehow triggered a loop which the workflow ran and this kicked off the update plugin, my criteria on running the update plugin were always being hit and then I was saving the whole record.  This triggered the plugin.  I ended up with initially 200 workflows had been kicked off for my custom entity.

Even after I fixed the criteria to run only when certain fields had been changed my workflow was still firing a few times.

This was valid because the custom entity was correctly being updated by the plugin but because I had retrieved all the fields the workflow was being triggered, this was not correct because the fields the workflow was monitoring were not actually have any data changed.

So I modified my code to only select the fields I was going to check/change and after I had done this the workflow stopped getting triggered incorrectly and a bonus my code ran a lot quicker.

Perhaps there is a lesson here for me, get the code selecting the correct fields from the start and don’t be lazy with retrieving and writing all the fields of an entity.

 

 

CRM 2011 – Debugging plugins using the Plugin Registration tool

I was having a bit of a nightmare debugging my plugins.  The plugin was working in my test case but when I deployed it and tried to run it from CRM, I was getting errors.

I had tried to setup remote debugging which I have done before but this time I was having problems because of some kind of firewall related problems and when I dropped my firewall the remote debugger could talk to my computer but the debugger wasn’t catching.

I then tried to get the profile/debugger working in the plugin registration tool but I kept getting stuck when it asked for a profile location, WHAT THE HELL IS THIS PROFILE.

I tried to google instructions for the profile/debugger but I couldn’t find anything but then out of the blue one of the blogs I follow wrote an article about it and saved the day.

if you want to use the plugin registration tool debug then follow these instructions

http://inogic.blogspot.co.uk/2012/06/how-to-debug-plugins-using-profiler.html

so basically you have to install and turn on profiling, then go into CRM, trigger the plugin.  This will then download your profile file.  Then in the Plugin Registration tool debug the plugin, choose your dll and newly downloaded profile text document, set the debug on your visual studio and attach the process to the plugin registration tool.  Now in the Plugin Registration Debug page, click Start Plugin Execution.

Basically the profile you downloaded is probably serialized variables and values which is now loaded into visual studio, allowing you walk through the code with the values you entered into CRM.

The tool is great and you can do it all from your PC.

Now onto the problems I was having.  I had set up a plugin to run on the post operation of an entity update.

What seemed to be happening was the main values of the entity were being copied but no related entity information was being created.  My code was using one of the related entities in a query.

To get round the problem I used the guid of the entity and retrieved the related entity information and then I could walk through the rest of my code.

CRM 2011 – Assembly must be registered in isolation

I got an error whilst trying to register a plugin, saying the assembly must be registered in isolation.

I found out something which I had forgotten, basically only Deployment Administrators can register plugins which do not run in isolation mode (e.g. in the sandbox).

The user I was using although was a System Administrator in CRM wasn’t in the deployment managers group so could only register plugins in the sandbox.

luckily for me the CRM in the field blog had a detailed article on the subject which you can read by clicking the link below

http://blogs.msdn.com/b/crminthefield/archive/2011/08/17/error-message-assembly-must-be-registered-in-isolation-when-registering-plugins-in-microsoft-dynamics-crm-2011.aspx

This bit below I found very interesting

In the Security Restrictions section of the following MSDN article it states, “There is a security restriction that enables only privileged users to register plug-ins. For plug-ins that are not registered in isolation, the system user account under which the plug-in is being registered must exist in the Deployment Administrators group of Deployment Manager.“

Register and Deploy Plug-ins
http://msdn.microsoft.com/en-us/library/gg309620.aspx

CRM 4 – Plugin registration problems – Could not load file or assembly

I tried registering a plugin in CRM 4 and it was hard work.

Firstly I had to build the Plugin Registration Tool, WHY???

I then initially tried to register my plugin, only to find I had not implemented the plugin interface.  I tried to compile the simple walkthrough in the SDK which had compile errors in!!

I signed my plugin (although it was pfx and snk)

but then when I tried to registered the plugin I got this error

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Crm.Sdk, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.
at System.Reflection.Assembly._GetExportedTypes()
at System.Reflection.Assembly.GetExportedTypes()
at PluginRegistrationTool.AssemblyReader.RetrievePluginsFromAssembly(String path) in C:\<path>\PluginRegistrationV2\PluginRegistration\AssemblyReader.cs:line 59
at PluginRegistrationTool.AssemblyReader.RetrievePluginsFromAssembly(String path)
at PluginRegistrationTool.RegistrationHelper.RetrievePluginsFromAssembly(String pathToAssembly) in C:\<path>\PluginRegistrationV2\PluginRegistration\RegistrationHelper.cs:line 49
at PluginRegistrationTool.PluginRegistrationForm.btnLoadAssembly_Click(Object sender, EventArgs e) in C:\<path>\PluginRegistrationV2\PluginRegistration\PluginRegistrationForm.cs:line 127

This forum post was very helpful the problem was the microsoft.crm.sdk.dll has to be in the same directory as the Plugin Registration tool.

I put this in the same folder but I was still having problems.

The reason for this was because I had copied in the 32 bit microsoft.crm.sdk.dll and instead I swapped this with the 64 bit microsoft.crm.sdk.dll and then it worked.

I don’t know why Microsoft make this so difficult because there is nothing worse than having to go through these problems when you are just setting up a system.

There must be some reason they don’t add the plugin registration tool as an Exe but I have never figured it out.