I was getting an odd error whilst casting a CRM dynamics spell, no it wasn’t a spell it was casting an ActivityParty to an Entity (although some people might say ActivityParty is rather magic or at least very complex)
Talking of bad casting, this would have been terrible
error in getproduct Unable to cast object of type ‘Microsoft.Xrm.Sdk.Entity’ to type ‘Hosk.Dynamics.Entities.ActivityParty‘.
It was on a plugin on the ServiceAppointment entity. What I was trying to do, is when the user updated the ServiceAppointment Entity. I would check the resources (which can either be a user or equipment).
If it’s equipment, I can then look up the value of a product and show a few product details on the ServiceAppointment record.
I was using early bound records but when I tried to get the serviceAppointment.Resources I got a casting error.
The odd thing was I could step through the code calling it from a console app but I was getting an error when the plugin was running.
The error was so odd I had to get someone to look at my code to check if I was doing a schoolboy error.
I knew it wasn’t a problem the Resources field was empty because I was checking it, it definitely had a value, the only problem was I got an error every time I tried to get it.
Finding the Error
To find the error, first I changed the code to throw an InvalidPluginException and this then puts out my tracing lines in the plugin. Which is good because I recently blogged about mocking up tracing and have been using tracing whilst debugging some plugins
So using the tracing line I could work out where the problem was occuring and see the casting error – FACE to FACE with the beast
The question was what value was in the resources field?
Debugging with the Plugin Registration tool
I used the plugin registration tool to set profiling on my ServiceAppointment then this spits out a file with all the serialized field values. You can then use this file to rerun the code in the Plugin Registration tool and attach the debugger to the plugin registration tool.
This is a lot better method than remote debugging because remote debugging stops the CRM server from running, so can hold up other developers/testers on that CRM instance
Here is a good article if you need to use the Plugin Registration tool for some debugging
I finally got to the ServiceAppointment.Resources, instead of a List of ActivityParty I found it had this
This was the line causing the casting error
List<ActivityParty> resources = (List<ActivityParty >)serviceAppointment.Resources.ToList();
The error it was throwing was this
Now that I was stepping through the code, I could have a look at the Entity attribute and retrieve the Resources value using Late bound code and this worked fine.
So the error was linked to the early bound class and there is some problem with it.
I had already spent way to much time writing this simple plugin, so I just used the work around getting the value from the Entity class and used late bound methods to get the data.
I did think about correctly the entities file but this would have been overwritten when anybody refreshed the early bound entities. So I decided to go with the code above and retrieve the resources using the early bound entity.
Plugin Registration tool
Using the plugin registration tool is an excellent way to debug plugins on a server but it can be done on your local machine, so it doesn’t impact the other developers working on the project.
All CRM Developers should know about the Plugin Registration tool, I mention this because some new CRM Developers have never used the Plugin Registration tool because they only deploy plugins using the CRM Developer toolkit.
So dust off the plugin registration tool and go a bit old school on your CRM.