Look inside .NET DLL files with Reflector

An application developer's job takes many shapes and forms; sometimes we create new applications from scratch, while other times we try to reverse engineer an existing application. Reflector is one option that makes it easy to take a peek inside existing assemblies.

During a recent project, I found myself in an awkward (though not unique) situation. The client had code in a repository as well as in production, but they were unsure about what functionality had actually been deployed. After lengthy discussions, we decompiled the production Dynamic Link Library (DDL) files and compared them to code repository versions to pinpoint what code was in production.

In this column, I explore reverse engineering compiled ASP.NET code, with an emphasis on the Reflector tool.


When compiled, source code is translated into Microsoft Intermediate Language (MSIL). The same MSIL is produced regardless of the source language (e.g., C#, VB, and C++). MSIL is processed by the Common Language Runtime (CLR) during program execution.

The entire set of classes and code-behind code is compiled into a single DLL file, which is referred to as an assembly. The assembly includes the MSIL as well as metadata, which provides additional information about security, versioning, and so forth.

It is possible to take the MSIL from an assembly and convert it back to .NET source code such as C# and VB. The first step is to extract the MSIL from the assembly. Microsoft's ILDASM tool, which is included with the .NET SDK, provides this functionality.

The next step is the conversion of the MSIL to .NET source code. There are numerous tools available to help with these tasks, so you can avoid the process of learning MSIL. A popular choice is Reflector, which provides an easy-to-use interface for peeking inside .NET DLL files.


The Reflector download is one zip file containing configuration files and a readme file, along with an executable. Once you run the program, base .NET assemblies are loaded; this includes mscorlib, System, System.Data, System.Drawing, System.Web, System.Windows.Forms, and System.Xml.

Reflector provides a File drop-down menu to load and process your assemblies. A Reflector option (which is available from the Tools menu) allows you to choose the .NET Framework version used by the tool. Decompiled assemblies are presented in a tree format. The user clicks a plus sign (+) alongside each assembly to expand and view its contents.

Reflector allows you to easily examine a class and its methods, as well as disassemble a class, by double-clicking it or using the Tools menu. The source code appears in a pane on the right side of the interface.

Analyze is another option that is available via the Tools menu. It processes the code and generates results detailing what assemblies it uses, along with the assemblies that use it.

Reflector supports C#, VB, Intermediate Language (IL), Delphi, C++, and Chrome. You can decompile an assembly and view its source in one of these languages.

An interesting byproduct of the multiple language support is the ability to easily translate from one language to another; that is, if you develop an application using C#, you can easily convert it to VB by loading its assembly in Reflector and viewing its source in VB.

Another great feature of Reflector is its extensibility, thus it is easy to create add-ons. The CodePlex site provides an excellent list of available .NET Reflector add-ins. A good example is CodeSearch, which allows you to easily search for text or regular expressions within disassembled code.

Other tools

While Reflector is a wonderful tool, it is not the only option. The following list provides a sampling of other tools.

  • Dis#: A commercial application that provides a trial version.
  • Decompiler.NET: A commercial tool that provides additional features like an obfuscator, language translation, and refactoring.
  • Spices.NET: A decompiler is only one part of this commercial toolset.


You may be worrying about someone grabbing your assembly and decompiling and stealing your hard work. Obfuscation is one approach for making it difficult to reengineer code; it makes it hard to understand code in its decompiled form. Obfuscation can be as simple as changing the names of variables, classes, methods, and so forth.

Other obfuscators allow you to make code flow harder to follow. It can be so confusing that a decompiler such as Reflector cannot do its job. Another option is encrypting source code and decrypting it at run time. Spices.NET provides a tool that promises to disable the ability to decompile code.

An in-depth examination of obfuscation is beyond the scope of this article, but it must be mentioned in a decompilation discussion.

One approach

An application developer's job takes many shapes and forms; sometimes we create new applications from scratch, while other times we try to reverse engineer an existing application. Regardless of the situation, we need to be aware of tools that help us tackle the job. Reflector is one option that makes it easy to take a peek inside existing assemblies unless obfuscation has been used.

Have you had to reverse engineer another developer's work? If so, share your thoughts and experiences with the Visual Studio Developer community.

Related TechRepublic resources

Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.


Get weekly development tips in your inbox TechRepublic's free Visual Studio Developer newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET. Automatically subscribe today!

By Tony Patton

Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a productio...