When you get beyond simple forms based applications and you're ready to tackle something a little more powerful, you discover that you might discover that you need programming tools that are a little powerful too. Framework has you covered!
One of the lesser known parts of the Microsoft Framework SDK is the Framework tools. These tools are a treasure chest of capability that a lot of programmers simply don't know about. One reason for that might be that you normally run all the tools from the command line (with one exception: the Assembly Cache Viewer, Shfusion.dll). That means DOS ... almost like in the old days! I can almost hear it now:
Ick! DOS! Eeeewwwwwwww!
DOS will live forever.
To introduce the tools, one that gets more attention than the rest is called ILDASM, or Intermediate Language DisAssembler. Let's look at this one in just a little more detail to see how the tools work.
To start with, open a DOS window - that's 'run the Command Prompt' program these days - and enter the command ILDASM.
Didn't work, huh? Bummer!
Unless you have done some extra steps, you received the error message, "ILDASM is not recognized as an internal or external command, operable program, or batch file." This is an example of one of the reasons DOS was so popular back in the day. The message really doesn't have much to do with what's actually wrong. The problem is that DOS needs to know where a program is as well as what the name is. If the "current directory" isn't the one where the program is, you have to add some 'where' information. You could "fully qualify" the command. If you're running Framework 1.1, the correct command is probably:
"C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\ILDASM.exe"
(including the quotes since there are lots of spaces in the name)
But then, with most DOS commands, the other files you want to use are probably in other directories so you'll still have problems ... other than typing all that correctly. The easier thing to do is to set the 'path' - the collection of directories that are searched automatically - to include the Framework SDK directory. Fortunately, Microsoft provides a batch file just to solve this problem. Unfortunately, you've STILL got to either qualify the command or navigate to the folder to execute it once. (You can't just double click it in Windows Explorer. That just opens a DOS window, sets the path for that window only, and closes it again.) The batch file is SDKVARS.BAT, so you can execute it with a command like:
"C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\SDKVARS.BAT"
... and as long as the current DOS window stays open, you can execute any of the Framework tools from any directory.
Now ... with that out of the way ...
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.. Although you run this program from the command line, it opens a regular window to display results. Try opening the ".exe" or ".dll" assembly from a program just to experiment. The information reported by ILDASM is in roughly two sections: the Manifest and the rest of the program just as your assembly is in those same two sections. The Manifest shows you all of the "metadata" - such as program dependencies - for your program and the actual Intermediate Language code is the rest of the display. 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 ... as clear and understandable as C# at least.
One of the first articles Microsoft published in MSDN magazine about .NET was about ILDASM called, "Bugslayer - ILDASM is Your New Best Friend".
There are a lot of other Framework tools, however. So many that Microsoft classifies them into four groups:
- Configuration and Deployment Tools
- Debugging Tools
- Security Tools
- General Tools
In our next article, we'll feature another of the .NET Framework tools, NGEN. This one is very interesting because it will be upgraded a lot in the next version of the .NET Framework.
