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:
Could I Implement This as an External Tool?
Dim objAssemblyValidator As New Assembly_Validator
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
). 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.
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 assembliesit 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.