All views and opinions are personal opinions of the Hosk

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

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.

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

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.

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

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.

HI Hosk – came across this awesome blog hoping to solve a problem I have.

I have a legacy CRM Project built in VS2012 using the old SDK and the old .crmregister XML files which meant you could deploy from the IDE. Do you have any ideas how I can migrate these old plugins to the current VS2017 projects which use the Plugin Resgistration tool, so I can to update the old assembly in CRM without creating a new assembly ? Cheers