testing presence of optional assembly
Hi,
I'm developing a Windows.Forms program which talks to differet types of database backends. We got a number of drivers from various vendors, but not all of them will be present on a particular user's machine.
I'm now looking for ways to dynamically discover whether an assembly is present. My best bet so far appears to be
AppDomain.CreateInstance( ClassName, Assembly.dll ).
I'm not really interested in the instance being returned. But if the statement completes without throwing any exception, then the assembly is present and the database driver is usable.
Am I on the right track ? Is this the way to test for drivers which may or not be present ?
[691 byte] By [
andrewsc] at [2007-12-17]
This will give you all the referenced assemblies but not the one that you load dynamically.
Dim components As System.Reflection.AssemblyName()
components = System.Reflection.Assembly.GetExecutingAssembly().GetReferencedAssemblies()
Determining whether an assembly exists by loading it will cause the assembly to be loaded and never released. I'm not sure that is what you want. For example if you are going to display a list of potential drivers to the end user then you would end up loading all the drivers even though you only needed one.
I would recommend that you simply look for the assembly itself using File.Exists. Of course if the file resides in the GAC then that won't work but given the example that you gave it would appear that you are expecting the assemblies to be in the same directory. If the file exists then you can probably load it. You won't know until you actually try but it avoids loading all the drivers just to test for existence.
Once you've decided to load the assembly then you can use Assembly.Load() to load it. There is also Assembly.LoadFrom() and Assembly.LoadFile() but these are not recommended. Load will handle the searching done by the loader and handles the case of the assembly already being loaded (for whatever reason). Once the assembly is loaded you can access it just like any other loaded assembly or cache the returned Assembly object for later use.
If for some reason you really want to try and load the assembly even if you don't need it then load it in a separate AppDomain. Once you've determined whether it is available or not you can unload the AppDomain and then load the desired driver into your main AppDomain. It is slower than the file existence test but it does consolidate the existence and load test into one. Add-ins normally work this way.
Michael Taylor - 10/13/05
Michael,
I can see the wisdom of loading an assembly (as opposed to loading an instance of a class from that assembly). In my first approach, I would have ended up with an object instance which I did not really need.
Tentative code - just by reading the helpfile
| |
myDoman = AppDoman.CreateDoman( "be_nice_please" )
try
myDoman.load( "vendor.data.interf", "vendor.dll" )
catch anyex as Exception end try
AppDoman.UnLoad( myDoman )
|
If control gets to the exception handler, then the assembly cannot be found.
Andrew
Your code looks fine but I wouldn't recommend setting up and tearing down an AppDomain for each driver as the cost is prohibitive. Instead I would create the AppDomain once and load all the drivers up initially to determine which are available and then tear down the AppDomain. Of course you can defer this until you actually need to load one of them so you take the hit only the first time through.
If you are in the situation where you don't know the drivers in advance and you are basically responding to a user's "request" then loading it into a separate AppDomain just to see if it exists doesn't gain you anything. If you attempt the load in the primary AppDomain and it fails you'll still have the same code you gave above. The AppDomain solution is good only if you are loading a bunch of assemblies for probing purposes.
The only change I'd make to your code is to check if the file exists before setting anything up. This handles a relatively common situation up front with little overhead.
Good luck,
Michael Taylor - 10/14/05
