This blog talks about a plugin error which I have seen a number of times when using the Plugin Developer Toolkit, it will discuss how to diagnose plugin errors in general.
Before I talk about plugins can I encourage people to vote on the connect item to get the CRM Developer toolkit working with Visual studio 2013, if you can’t wait for Microsoft to fix it then read my blog post CRM Developer Toolkit Alternatives
Hosk CRM Brain
I like to think of my blog as my CRM brain uploaded to the internet, so whilst reading this you are currently crawling through my CRM brain. This allows me to search my CRM brain when my real brain forgets how I resolved a problem, actually sometimes I even forget I have experienced a problem and get pleasantly suprised when I have found not only did I have the problem before but I blogged the solution.
The benefit of me blogging about CRM is I benefit and other people who read and search my blog.
My goal in writing articles focused on errors is not only to write about how to resolve the issue but additionally look into the cause of the problem and , the WHY.
Knowledge helps when things go wrong
There is always a difference between theoretical knowledge and practical knowledge. You can learn the theory of something but find it’s different when you try to use the theory in practical use (e.g. after reading about plugins you then try to write a plugin) you there are gaps in knowledge which you quickly find.
When developers start to plugins they usually go through
- learn to write plugin code, find lots of errors
- try to deploy plugin, error haven’t signed the plugin, error permissions etc.
- Slowly but surely the developers experience fewer problems or problems they know how to resolve
Indepth knowledge of how Microsoft Dynamics CRM works and the underlying plugin infrastructure becomes extremely important when things go wrong. When errors appear and hold up development, developers need to understand the cause of the error but why it’s complaining, the answer is usually understandable if you understand
- how the CRM developer toolkit works
- The various parts of the CRM Developer toolkit
- The CRM plugin execution framework
- The roles and privileges needed to deploy plugins
Some useful Hosk Plugin blog posts
- CRM 2011/2013 – Common Plugin Errors and Isolation Mode
- Understanding Plugin sandbox mode
- CRM 2015 – Understanding impersonation in plugins and knowing when to use it
- CRM 2015 – How to decompile a plugin Assembly (DLL)
- CRM 2015 – Understanding the plugin profiler and a puzzling error
The CRM developer toolkit is great (which is why I get annoyed it hasn’t been updated because it automates a lot of the repetitive actions needed to deploy a plugin using the plugin registration tool.) but I feel CRM Developers should learn how to use and deploy plugins using the plugin registration tool.
I use the plugin registration tool to inspect what plugins and steps are deployed and the ability to change the view to see what plugins are deployed for each entity is really useful when investigating bugs on CRM solutions you are not familiar with.
Most of the time you don’t want to mix using the plugin registration tool and the CRM developer toolkit because the CRM developer toolkit will overwrite the changes you make manually next a developer uses it to deploy CRM customizations.
The plugin registration tool is great for viewing the plugins deployed and its portability allows you to use it in customer environments.
If the CRM Developer toolkit gets in a mess you might need to use the plugin registration tool to quickly update or deploy a plugin whilst you fix the plugin developer toolkit.
I had an error previously but the problem was the CRM developer toolkit had got out of sync and I struggled to resolve this problem. You can read about my frustrations with the CRM Developer toolkit
Dealing with Plugin errors
If When you experience a plugin error I would recommend you first read my blog on common problems because I cover the most common errors.
If you don’t find the answer then stop and think about the potential cause of the problem. Many developers can go into a mild panic mode when they encounter an error, instead of logically thinking about the problem they instantly go and get a senior developer to help them.
Then when the senior developer is at their desk, they explain the problem. The process of explaining the problem to the developer, the solution to the problem can become clear. This is known as rubber ducking or I call this Cardboard developer
When you encounter a plugin problem or CRM developer problems, follow these steps
- Engage Brain\Think
- What’s happening?
- What should happen?
- Make a list of the possible causes of the problem
- Investigate your list
If you can’t resolve the problem, you can then at tell the developer what you know, what you have tried.
I don’t encourage any developers to suffer in silence but it’s more beneficial for you own personal learning if you try to understand and resolve problems yourself. The major benefit of trying to resolve the problem yourself is you get in the habit and become less dependent on the help of your colleagues.
Don’t Assume, know
Don’t Assume, Know is a Hosk mantra I tell myself when investigating problems or debugging. I have wasted many hours investigating problems and looking for solutions based on an incorrect assumption. When dealing with problems don’t assume anything, check assumptions and cross them off. Lots of times you will find the problem.
Plugin Error Messages
The error messages Microsoft Dynamics CRM throws are a mixture of a confusing statement with a nugget of truth tucked inside. To developers new to CRM development they are just unhelpful messages.
As your experience and knowledge of CRM development increases you will find they often point you in the right direction but you need to have built up a map of the CRM landscape, so you know where to go and check.
Plugin Error Example
This is common error I have experienced a few times but I was trying to deploy a plugin using the CRM developer toolkit and I got this error
Error registering plugins and/or workflows. Plug-in assembly does not contain the required types or assembly content cannot be updated.
Lets break down the message to try and decify the problem
- It can’t register the plugin/workflow
- Plugin Assembly does not contain required types or the assembly cannot be updated.
- So we know the plugin assembly (the DLL) exists but it cannot update it.
The first thing to do is know not assume. So I opened the Plugin Registration tool and found the DLL. I could see it had three steps.
I then looked at the RegisterFile.crmregister file and found this had two steps.
The problem was because we were trying to update an assembly with 2 steps but the assembly had 3 steps. It couldn’t update the assembly because it was too different and this error message was letting us know (in a slightly confusing way).
I have experienced this problem before and the solution to the problem is to unregister the Assembly and install it again.
This problem has occurred when I have created new plugins and sometimes when I have updated a plugin maybe in a different solution but for some reason I couldn’t update the DLL.
In this case how the extra step got into the assembly was a complete mystery but it’s OK to delete the plugin assembly because I knew I was going to deploy it again and install a new version of the Plugin assembly.