We are getting really close to the .Net world with incremental steps (a big hurray here), and in order to understand some of the inner workings of a particular feature that you are using at a point in time, you will need to dig a little deeper (of course, that is if you are into this).
Today's topic is about decompiling a .net assembly in order to know what it is working in a way that it's not clear to you. I am pretty sure you have heard about .Net Reflector, maybe also dotPeek, ILSpy. They all are great, do the job properly.
However, for the ease of use you can always go to ILDASM, it's there on your system (I assume you have the .Net framework in place) and ready to run. Couple locations you can find it is at: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\ILDasm.exe or C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\. Basically you run the decompiler, load your assembly and understand what you should expect from it.
The main aspect to understand here is why you would do that.
Let's say you have a constructor that is not clear what is doing. Based on it you will get a behavior that you are wondering if you can alter it or not.
My example, from years ago, is the EPDocuGet class from the Microsoft.Dynamics.Framework.BusinessConnector.Proxy assembly. I wanted to implement a different entry point, there were some constructors that took some parameters, just wasn't sure if they are working or not. Decompiling the assembly helped me understand what I can achieve. Simple as that.
So, if you do not find a method on MSDN, decompile it.
No comments:
Post a Comment