.net miner

If you get ReflectionTypeLoadException during loading an assembly to your AppDomain or running an assembly, it will be hard to find which assembly cause the problem from the given standard error.
Generally the exception says something like “Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.“

You must have a look to the LoaderExceptions in the ReflectionTypeLoadException to understand exact problem. That property contains the whole resolution fail exceptions in it. But if you don’t have source code of your program or if you can not debug your program then it will be hard for you to access LoaderExceptions during run time. To solve this problem and take some help, you can use AssemblyLoadLogger, which I developed it for this purposes.

When I was newbie in .NET, it was a shocked for me to learn that .NET assemblies can be decompile. But today I know that this is a normal situation for a language which is compiling to an intermediate language. As we know that, after compiling a .NET project the output will be in MSIL (Microsoft Intermediate Language). And during the application lifecycle this codes will be compiled to Native Codes by the JIT (Just-In-Time Compiler) when they first used and cached in that computer for the future usages. Anyway this is another subject for us how JIT works, but here the problem is our assemblies are in MSIL format which has about 229 opcodes and all these opcodes has a standard working procedure. So if we know these opcodes and how they are working, we can produce the .NET codes by reverse engineering. This is simply what decompilers do. But why there are no stable decompilers for the native exes?