CRM 2015 – How to decompile a plugin Assembly (DLL)

This blog post looks at how to decompile plugin code because I had a problem recently where I needed to do it.  The process will work in all version of CRM because fundamentally it works at DLL level rather than CRM level.

It’s a useful to understand because there are some instances where you need to know what code has been deployed because it might be different from the code you have or the code in your source control.

The problem – Why isn’t my fix working?

A bug fix I had deployed and tested in our dev environment and test environment suddenly stopped working when deployed to the customer environment.

This isn’t an unusual problem but an annoying one for developers.

Don’t assume, know

When bug fixing and testing try to avoid the trap of assuming because assumptions are often wrong, resulting in missing the obvious source of the problem, spending time testing other possible reasons for a problem.

Usually when a bug fails on a different environment I want to recreate it in the DEV environment where I can easily debug it.
For this problem we have two internal instances

DEV
TEST

I tested my fix in DEV and it seemed to work and then I tested the fix in internal TEST environment and found my fix didn’t work, why?

Finding the plugin code deployed

There are instances when you need to find the code deployed in a plugin. It’s possible to version plugins but CRM developers don’t bother versioning their plugins and I currently don’t version the CRM plugins.

Plugins can be versioned in the same way solutions are version in CRM

major.minor.build.revision

You need to think about versions and solutions because when you change the major number of a plugin assembly CRM considers it a completely different plugin assembly

Microsoft has a good article on Plugin Assembly

This article on how to upgrade version

Hardcore CRM: Do a major upgrade of a plugin version!

What to do if you don’t use assembly versioning

The problem I had was how could I tell what code was inside the plugin and if my fix was deployed?  The code in TFS (Source Control) was correct and up-to-date but I tested the functionality and could see it wasn’t working.

I decided to download the plugin assembly dll and decompile the code.

The tools I used was

XRMToolbox

Go to releases and click latest release if you want to download the application not the source
https://github.com/MscrmTools/XrmToolBox/releases

The XRMToolbox has a tool called Assembly Recovery Tool. This tool allows you to connect to a CRM instance, it loads all the assembly DLL’s (which can some time), you can choose to download any of the Plugin assemblys(dll file). This will give you the dll, which you can decompile using a different tool.

Once you have the DLL file you can decompile the dll using a tool such as

ILSPY

There are lots of other decompilers out and the main reason I use ILSPY is because its free

To use the decompiler you open it up, select a DLL or copy one to the application, below I have selected a HoskCRMDev2013 plugin.  The dll’s in blue are dependant plugins

If you then click on one of the methods, it decompiles the code, which you can view it in the yellow right hand screen.

ILSPY has a few neat options to save the to file.

A few notes on decompiling DLLS

DONT decompile DLL’S you or the company you work for doesn’t own because basically you are viewing the source code.

I’m not sure about the legality of it but it’s probably illegal, particularly if you don’t own the intellectual property.

If you aren’t sure if you should decompile a DLL think about it like this.  If you went to the owner of the source code and asked to view the source code, would they let you?

A common cause of decompiling plugins/custom workflows is to see what has been deployed if plugin versioning is not used.

Be warned decompiled code is slightly different, often the variables don’t have the same name.

If you are concerned about your dlls being decompiled there is a tool to encrypt them, I haven’t used it.  The discussion on StackOverflow is a good place to start if you are interested

Protect .NET code from reverse engineering?

When might you need to decompile a DLL?

Surprisingly there are quite a few scenarios where you might need to decompile a DLL, I will go through some of the common scenarios but the

Lost source control

I have seen scenarios where a company has lost the source control for code which has been deployed.  Often its old legacy systems and most people who worked on the project have left the company

Deployed with source control checked out pending

A developer deploys some code, forgets to check in the code.  The developer then might leave the company, go on holiday and can’t be contacted.  You need to know what code has been deployed and what code might not be checked it.

Plugin won’t deploy from CRM Developer toolkit

Sometimes a plugin won’t deploy and you will get an error like this

Error registering plugins and/or workflows. Plug-in assembly does not contain the required types or assembly content cannot be updated

The reason for this error is often because the deployed assembly file (DLL) is different.  It might have an extra step and you are not updating the file but trying to replace it.  CRM doesn’t like this.

I had an example of this recently and there was an additional step in the deploy DLL.  I used the plugin registration tool to compare the steps but I wasn’t sure what was in the extra step.  So I download the DLL and looked at the code.

What has been deployed

This is the problem I was experiencing for this bug.  I needed to check if the code deployed was the same as the code in source control, the only way I could do it was to decompile the code and compare.

Plugins without versioning

A common cause of decompiling plugins/custom workflows is to see what has been deployed if plugin versioning is not used.

Multiple Developers Versus Source Control

When you have multiple developers working on a project, source control can sometimes lead to problems with people not getting the latest code and deploying an older version

Who deployed the different plugin?

I was wondering how the different plugin version got deployed. I wondered if I could work out what solutions were imported

I remember review a useful tool a while ago the Solution History tool, which is a tool which works with the XRMToolbox

You can download the tool here

The tool usefully told me what solutions had been imported and what files were included.

I could see the solution had been changed and who imported but I couldn’t tell what version of the Plugin Assembly had been deployed.

This tool would be extremely useful if the project you are working on imports multiple solutions without changing the version number.

What gets updated when you import a plugin to the database?

In the background when you import a plugin it updates system entity called plugin. I wondered if I could select these entities to see when they had been updated.

The problem is you can’t select system entities in an advanced find, so I remember another tool which works with the XRMToolBox the FetchXML Builder

You can get the tool here

This tool is useful because it has GUI interface to allow you to create Fetch XML queries. This means you can select system records.

The real beauty of this is you can create FetchXML queries and then use them in your plugins.

I wanted to use the tool to easily query the system entity of plugin

Which produces the FetchXML below

<fetch count ="50 " ><entity name ="pluginassembly " >< filter>< condition attribute= "name" operator=" eq" value ="Full Assembly Name " /></ filter></entity></fetch>

This allowed me to retrieve when the plugin was changed and by who. I was wondering if someone had directly deployed a plugin to the Test environment and bypassing the Solution import phase but it turned out not to be the case.

I couldn’t work out who had deployed an old plugin version and the important point was I had the resolution to the problem (although you would like to be confident it wouldn’t happen in the future)

Summary

This blog should show you how to download and decompile a DLL file.  There are certain scenarios where you aren’t sure if the code deployed is the same as the code in your source control.

Downloading and decompiling DLL’s is another tool to put in your development bag, make sure you use it for good not evil.