eflection is truly a paradigm shift for developers using Microsoft's line of development tools. The runtime availability of assembly metadata provides developers with new flexibility and the ability to develop interesting software tools. Developers often use reflection to load assemblies and instantiate classes dynamically, or to invoke methods, but you can also use reflection to inspect assembly metadata.
That capability leads to a way to solve an often-experienced problemapplication deployment failures due to missing project dependencies on a machine. When you deploy a new .NET DLL or executable, knowing that a dependency is missing would aid greatly in fixing the problem before
customers report the problem. Using reflection, you can easily build a tool to validate an assembly's dependencies and report on which ones are missing.
This article describes a tool you can use in your own projects to report missing dependencies. For server or middle-tier applications, you can call the validation code directly from the application. For client-deployed applications, you can include the code as a diagnostic tool for troubleshooting problems in the application. Before building the tool, here's a quick tour of what reflection is and how it works.
At its most basic level, reflection provides a way to inspect assembly metadata, including the classes exposed by the assembly, the methods and types found therein, attributes assigned to various objects, and other related information, such as referenced assemblies and assembly version numbers. Using this information, reflection also provides a way to dynamically instantiate classes and invoke methods on those classes in a more-or-less late-bound manner. Reflection has been available since the original release of the .NET framework.
In this article, you'll see how to use reflection to expose assembly metadata. Specifically, to build a dependency validation tool, you need to discover which assemblies an application (which itself is an assembly) depends on for proper operation. The validation tool verifies that all a project's primary dependencies are available, and that any secondary dependencies (those required by primary dependencies) are available, and so on, until the entire dependency hierarchy has been traversed. As you will see, this process is surprisingly fast, even for projects with deep dependency levels.
How .NET Resolves Assembly References
To get started on the development of the validation tool, you must first understand what it means for an assembly to be availablemore specifically, how you can know for sure that an assembly can be found and loaded successfully at runtime. Unlike the registration model used by COM, whereby components are registered in the machine's registry, .NET by default does not register its components in a centralized fashion (with some exceptions, which aren't relevant to this tool). Instead, the .NET Framework depends on a well-defined process to find referenced assemblies. Unless assemblies are registered in a configuration file or stored in the GAC, the framework uses a probing process to find referenced assemblies.
Because the probing process traverses certain directories in and hierarchically beneath the directory where the hosting application is located, assemblies not stored in the GAC or registered in a config file must be located in either the hosting application's directory or in a particular directory below the application root directory. This process is also documented at MSDN.
|Author's Note: Most of the functionality described in this article is exposed through the System.Reflection namespace. You should add an Imports statement (if you use VB.NET) referencing this assembly in each of the code files you create that use reflection.