Retrieve, Change, or Create Program Information

You frequently need to be able to access information about a program from the program itself. For example, suppose you need to adjust the size of a program's form to match the screen. The following illustration shows one way to get that information.

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

The most common way to do this in VB.NET is called "reflection" but there are a lot of ways to get information about a program, the computer it's running on, or the state of the program. In this article, I have consolidated several articles into one and added new information to explain some of these different techniques. The goal is to provide a few examples in several different areas rather than a comprehensive list of everything. You can always get the comprehensive list from MSDN. (Some suggestions about searching for this kind of detail can be found in this segment of the VB.NET Express tutorial.)

Reflection

.NET's reflection is a completely new technique for many VB 6 programmers. The basic idea behind reflection is that since .NET requires that a lot of information about programs be saved along with the program, it's possible to access that information at runtime. ("Data about data" is called "metadata".) The 'official' definition of reflection at MSDN (found in the .NET Framework Class Library documentation for the System.Reflection Namespace) is

"The System.Reflection namespace contains classes and interfaces that provide a managed view of loaded types, methods, and fields, with the ability to dynamically create and invoke types."

Let's break that down just a bit to see what it actually means.

First, since the System.Reflection namespace is part of mscorlib ("Multilanguage Standard Common Object Runtime Library" - the DLL that also contains fundamental types like String and Integer), you don't have to include it in your program before you can use it. Like all objects, you can view the classes and interfaces with the Object Browser ... or just let Intellisense suggest the right one. "Managed" is a favorite .NET term and it just means that, like all VB.NET code, what you can do in your program is controlled by the CLR (Common Language Runtime). The types, methods, and fields that you can access are in types that are currently loaded into memory. And you can do all this dynamically, that is, while your program is executing.

But possibly the most valuable use of reflection in VB.NET is described in that last clause, "... with the ability to dynamically create and invoke types." Reflection gives your program the ability to mesh with code that hasn't even been written yet by retrieving the "types" (you can think of this as meaning "objects") and figuring out what they do and how to use them using the metadata saved with the program code in the .NET assembly. And do all this at runtime!

For example, you can write a program that allows users to "plug in" additional code modules and use them. (This advanced use of reflection isn't what this article is about, however, because it would take more space to describe than I have available here to explain it and provide the examples.)

One of the main reasons all this great information is available to you is a result of .NET's new architecture of assemblies and metadata. An "assembly" is a .NET application plus it's self describing information. This is the information that the classes and interfaces in the System.Reflection namespace lets you access.

A .NET assembly usually consists of the sections shown in the illustration below. It's also possible to split an assembly into several files.

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

As an example of how to get metadata in the assembly, you might need to know the path to the executable of your program. You might design the system to read another file located in the same directory, for example. To get this information, just add this simple code:

Dim myAssemblyPath As String
Dim a As Reflection.Assembly = _
System.Reflection.Assembly.GetExecutingAssembly()
myAssemblyPath = _
   a.Location.Substring(0, InStrRev(a.Location, "\"))

The variable myAssemblyPath will then contain the path to the directory your program was started from.

The Windows system path is Environment information, rather than metadata in the assembly. Retrieving this information is demonstrated later in this article.