Every now and again I run into the unfortunate circumstance where someone has lost the source code to a Dynamics CRM plugin (or something similar).
When you encounter this type of situation your only hope is to decompile the source using the plugin assembly’s DLL file and spend a good deal of time modifying the source code to get close to what the original author wrote.
Today my tool of choice is JustDecompile from the fine folks at Telerik.
Decompilation is not an exact science simply because the code the compiler ended up generating is not exactly like the code the author wrote. Most of the time this is caused by optimizations that the compiler has inserted which replace the original author’s code with code that it thinks is “better” or in some cases, just because.
So when reviewing a decompilation, it is sometimes hard to make a determination if what you see is compiler-generated or user-generated, especially when it is not your code. And I should note that I have seen a lot of code written by people whose main job was not that of a developer, who grabbed some code out of the Dynamics CRM SDK or off of the Internet to solve a problem, without really knowing what they were doing.
So when you look at the decompiled code, you are always asking: did they write it this way, or is this the way it was compiled?
Today I ran into something quite different.
First off, the using statements look very strange:
And some of the comparison operations used methods that I had never seen before:
Which is in the Microsoft.VisualBasic.CompilerServices namespace.
Very odd. Why would a developer writing C# use Visual Basic.NET assemblies?
The answer is: They would not. This code was originally written in VB.NET, not C#.
So I am still going to use the C# decompilation code, but knowing that this was originally written in VB.NET helps me understand a little bit better some of the code that I am seeing.
Just another note to put into your book somewhere.