[Disassembly] c# Disassembly Tutorial.net Program Decompilation Tool (ILSpy)

I used to use Reflector to view some information about the .NET library, but since February 2011, Reflector has been moving to paid software, so developers who love free software have turned to developing their own decompiled software. So ILspy was born because of luck. ILSPY is an open-source tool that replaces reflectors, and it decompiles code similar to reflectors.

SharpDevelop is another and only . .NET open tool, and it is open source. It also offers pretty good features, almost rewriting Visual Studio. In the latest version, support for Visual Studio's solution security files and project files has been added directly. ILSpy is a decompiler tool from the SharpDevelop group and is also open source, and its debugger and decompiler are described below.

Screenshot of ILspy's interface

ILSpy's interface is similar to Reflector, with tree controls showing the assembly and its type on the left and the corresponding source code on the right. The basic decompilation function is not bad compared to Reflector, and sometimes it can even be decompiled with ILSpy for assemblies that cannot be decompiled (because of encryption) with Reflector.

The basic type decompilation function is available

Now only decompiling source code into C# and IL languages is supported, not VB.

The renderings are:

ILSpy's code saving feature

When clicking on a type, selecting File-> Save Code decompiles the current type and saves it to the specified file, and when selecting an assembly, Save Code is saved as a project (csproj) file and all its types are added to the project.

ILSpy's debugger feature

The debugger here does not refer to Visual Studiosourcelevel of debugger, but refers to the debugger of the assembly. Reflector has an addin that can be attached directly to Visual Studio to debug third-party type libraries without having to decompile the third-party type libraries and add them to the project in the form of source code.

ILSpy also has this feature, which allows you to debug third-party assemblies directly, with two options

If the third-party type library is an executable, you can start the program with Debug an executable.

If the third-party type library is an assembly (DLL), you can attach it with an Attach to running application to start debugging the assembly.

As you can already see from the image above, its usage is the same as debugging source code. Where you need to monitor the variable value, set a breakpoint, and when the program runs to this point, you can observe the value of the variable by monitoring the form.

The difference between the two is that when Attach to a running application is debugged, if the code is optimized by the compiler, the monitor will not get its value.

As shown in the image, the value of the variable num being debugged cannot be displayed because the code has been optimized. The official recommended method is Debug an executable

As with debugging .NET source code in Visual Studio, you can Step into, Step over, continue, and the status bar will show stand by, running, and debugging.

In addition to debugging the code in C#/VB form of the assembly, it can also be debugged in IL code, as shown in the figure below

ILSpy's debugger exists as a plugin, make sure to include the ILSpy.Debugger plugin.

But debugging. .NET assemblies must require PDB files. However, ILSpy does not generate PDB files (no PDB files are generated), and it cannot debug ASP.NET web applications and web services.