RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Use Reflection to Validate Assembly References—Before Your Customers Do : Page 3

Developers are familiar with reflection as a way to create object instances, and discover and call object properties and methods, but reflection's usefulness extends even further—you can also use it to create a diagnostic tool to discover and validate dependencies for deployed code, and to report missing dependencies.

How to Include This Validation Tool in Your Project
To use the AssemblyValidator tool provided in the sample code in your project, you will need to build the AssemblyDependencyValidator project, and add a reference to the resulting AssemblyDependencyValidator.dll file in your application project. The sample code includes a "big button" style window to call the validation code, but in a deployed project, I recommend either calling the validation code from a menu item or via a command line switch. If called via a command line switch, the application could dump the results of the validation test out to a text file, letting you manage the whole process using your deployment tool.

After setting a reference to the AssemblyDependencyValidator.dll assembly, create an object of type Assembly_Validator, and call its ValidateEntryAssembly method. When this process completes, you can instruct the Assembly_Validator class to display the results in a window by calling the DisplayValidationResults method, or you can direct the results to an output file by obtaining the results of the validation process in string format from the ValidationResults property, for example:

   Dim objAssemblyValidator As New Assembly_Validator
Could I Implement This as an External Tool?
You've probably noticed that, as written, the AssemblyValidator code must be included with your project, but you may come to the conclusion that a validation tool would be better built as an external tool. Such an external tool would let users select an assembly (exe or dll). The tool would load the specified assembly and then recursively validate its referenced assemblies as described above.

While this is possible, it will cause problems due to the probing rules used by the .NET Framework. For the sample validation application discussed in this article, the implication of this probing process is that it cannot attempt to verify assembly availability remotely. If the validation tool were written as a separate executable and run from a different directory than the executable whose dependencies we wish to verify (target executable), .NET's probing process would traverse a different set of directories than if the probing process were running from the target executable's directory. Therefore, to accurately validate the availability of referenced assemblies, the validation code must run from within the target executable.

For example, if the specified assembly references DLLs that aren't registered in a config file and aren't in the GAC, then when the AssemblyValidator attempts to load the specified assembly (using .NET's probing process), it likely won't find it.

One solution to this probing problem is to implement your own probing logic, based on the same rules used by the .NET Framework. However, that could prove problematic if future releases of the .NET Framework alter the probing rules. Further, you would also have to manually parse the application and machine config files for information related to assembly registration. In addition, you would need to probe the GAC for the assembly. With that said, it's certainly possible to create a custom assembly loader that mimics the process used by .NET, and doing so might result in a more generally useful tool.

Another solution to the probing problem would be copy the validation application to the same directory as the target application, and run it from there. While that's certainly possible, there's a hint of a lack of elegance in this solution, and it hardly seems worth the effort, even if you automated the process of copying the validation tool and running it in the appropriate directory.

Final Notes
It is important to understand that just because an assembly is referenced does not necessarily mean it will ever be used by your application. The assembly may contain only classes that your application does not use. In many such cases, your application would run correctly in the absence of these referenced assemblies. Keep this in mind as you run this tool.

Another potential problem arises when an application uses reflection to late-bind to assemblies. In this case, the assembly metadata cannot publish information about those assemblies. If your applications make frequent use of late-bound assemblies, remember that because the AssemblyValidator relies on metadata created at compile time, those assemblies will not be inspected.

It has always been a bothersome task to verify the availability of a newly deployed assembly's referenced assemblies. In fact, this very issue has caused countless problems for many software groups. The problem isn't new for .NET assemblies—it was a problem for COM deployments as well. However, through reflection, .NET has provided the technology for validating these dependencies easily.

I recommend that you include a validation tool similar to the one described in this article in all your executables. When included as a piece of a larger application framework, it serves as a great tool to help make software more robust and manageable.

Michael S. Jones is the Director of Systems Architecture for Passport Health Communications, Inc., a national healthcare technology provider connecting hospitals, physician clinics and outpatient centers with payer and patient information to facilitate and improve their revenue cycle process. Michael, his wife, and three children live in Franklin, Tennessee where he spends his spare time reading and enjoying time with his family outdoors. .
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date