When you get beyond simple forms based applications and you're ready to tackle something a little more powerful, you might discover that you need programming tools that are more powerful too. This article is about the ILDASM utility - the Intermediate Language Dis-Assembler.
About Visual Basic offers a series of articles about the Framework tools. Links to all of them, and an introduction to the .NET Framework tools, can be found at: Framework Tools - About the Tools. (Note ... The series is still incomplete as of this writing, however.)
ILDASM gets a lot of attention because it's one of the most useful tools for discovering just exactly what is in your VB.NET assembly - the fundamental unit of code in .NET. The assembly is a version of your program written using the real code for .NET, a language called IL. (Intermediate Language - Sometimes called MSIL to differentiate it from CIL, the standardized Common Intermediate Language.) IL is the key part of .NET that makes it possible for all .NET languages to share the same .NET Framework. When you "Build" a Visual Basic .NET executable (or a C# or J# or any .NET language), what you're actually doing is creating the source code for the IL version of the program. The final compile into actual machine code - the version of your program that can be run by your computer - isn't done until the last moment when you run the executable. You can read more about this in the article Assemblies in .NET.
Although you run this program from the command line, which you might know as "DOS", it opens into a regular window. Before starting ILDASM, try running ILDASM with the /? option. Most programs that you run with in a Command Prompt window let you see some help output on all the options this way.
--------
Click Here to display the illustration
--------
Try opening the ".exe" or ".dll" assembly from any program just to experiment. You have to Build the solution first and open a Command Prompt window. The introduction article linked above tells you how.
--------
Click Here to display the illustration
--------
The information reported by ILDASM is in two sections: the Manifest and the rest of the program. This is the same way that your assembly is organized. The Manifest shows you all of the metadata - data about data such as program dependencies. The program dependencies are what makes .NET capable of things like "XCopy" installs and avoiding "DLL Hell". Try double clicking on part of your program and you'll see that the actual IL code that is produced by the .NET compiler is, well ... at least as clear and understandable as C#. The illustration below shows a test VB.NET program and the ILDASM display of the same program. Note that different types of objects are identified by specific icons. Double-clicking the Test_Method icon opens a code window for that method to display the IL code.
--------
Click Here to display the illustration
--------
"Kewl!" I hear you saying, "But what good is it?"
There are two basic reasons that you might have to use it. (Well ... three, if you throw in "curiosity" as another reason.)
1 - To work with the IL code for a program directly.
2 - To see what the code is really doing.
The first reason is probably one that only really hard core techies will have. You can output the IL code for a program into a file, modify it, and recompile it if you have a need for this level of technical precision. The command to create a file for the program above is:
ILDASM "C:\...\ILDASM_Test.exe" /OUTPUT:"C:\...\GenOutput.il"(The paths to the executable and the output are not shown and the name of the output file can be any legal name.)
If you check out the actual IL code for the same program by outputting it and then displaying it in Notepad, you'll see that ILDASM does make it a lot easier to understand.
The second reason is actually the only one I have ever had, but I do that fairly frequently, usually to compare the IL code generated by C# and VB to study the difference. In a recent support article, Symantec recommends using ILDASM to determine whether an executable file is WIN32 or .NET. And you can often see whether an effort to make code more streamlined by using one kind of statement rather than another (CStr or ToString?) actually makes a difference.