Problem with dynamically loading classes

[Scott Hodson]

I'm trying to dynamically instantiate database connection objects but it
keeps giving me an error

Consider this code (I have set up proper "using" clauses)

==========================
1: System.Data.Odbc.OdbcConnection whatever = new
System.Data.Odbc.OdbcConnection();
2: Type classType = Type.GetType("System.Data.Odbc.OdbcConnection", true);
3: IDbConnection connection = (IDbConnection)
Activator.CreateInstance(classType);
==========================

I know the System.Data.dll assembly is being loaded because I can see it
being loaded in VS.NET's Output window, and the first line of code works
fine. But on the 2nd line I get (assume my app is called MyApp.exe, and the
name of the assembly is "MyApp")

==========================
An unhandled exception of type 'System.TypeLoadException' occurred in
MyApp.exe

Additional information: Could not load type System.Data.Odbc.OdbcConnection
from assembly MyApp, Version=1.0.1290.31707, Culture=neutral,
PublicKeyToken=null.
==========================

I have done this sort of thing successfully when loading classes that are in
the app's assembly, but, for some reason, I'm not able to do it with classes
in other assemblies. If I set the 2nd parameter on the 2nd line to false or
take it out I get an error on line 3

==========================
An unhandled exception of type 'System.ArgumentNullException' occurred in
mscorlib.dll

Additional information: Value cannot be null.
==========================

Because the GetType() failed and returns a null Type object...

Help!

P.S. In case you're wondering why I'm doing this, I'm trying to create a
database object factory for an app that needs to support SQL, Oracle and DB2
and based on some config settings I want to instantiate different database
objects that implement the same System.Data interfaces but in different ways
and I want to compare the performance of System.Data.SqlClient,
System.Data.Odbc to DataDirect's .NET Connect drivers for
SQL/Oracle/DB2/Sybase.

http://www.datadirect-technologies.com/products/dotnet/dotnetindex.asp

 

[Scott Hodson]

PS, I've tried using Assembly.Load() but I couldn't get that to work and in
VS.NET's output window it said that the assembly was loaded so I figured it
was already loaded into the AppDomain.

 

[Scott Hodson]

Thanks, I knew that but I had trouble getting the fully qualified assembly
name but after discovering the using Type.AssemblyQualifiedName property I
figured out the full assembly name
Type temp = Type.GetType("System.Data.Odbc.OdbcConnection, System.Data,
Culture=neutral, PublicKeyToken=b77a5c561934e089, Version=1.0.5000.0",
true);

I must say this is much easier to do in Java. If the class is in the JVM's
CLASSPATH, you just call Class.forName() and it returns a type for you. In
..NET I have to know each assembly's current version, public key, and culture
info to work with it. I can see how this can be handy in versioning,
though. Still, since I already had the assembly loaded, I think the
GetType() default search should at least search types in all assemblies
loaded into the CLR, not just the app's assembly, because doing it this way
will probably make this code break when, say, ,NET 1.2 comes out and the
System.Data version number gets bumped up (assuming I'd remove .NET 1.1,
which I would normally do)

 

[Scott Hodson]

Yeah, the docs mention some wildcard possibilities but I haven't toyed with
those. Before I tried

Type temp = Type.GetType("System.Data.Odbc.OdbcConnection, System.Data,
Culture=neutral")

and

Type temp = Type.GetType("System.Data.Odbc.OdbcConnection, System.Data")

and neither one worked so it definitely needed more. Wildcarding the public
key token is probably not an option either and is required since it's a
strongly-named assembly.

- Scott

 

[Suzanne Cook [MS]]

Never use LoadWithPartialName(). See
http://blogs.gotdotnet.com/suzcook/PermaLink.aspx/87646756-a94d-4c3a-a313-56c29a59b22d
for why not. It may seem like a hassle to give the version, but it's
actually in your best interest, to avoid dll hell.

Use Assembly.Load() the full assembly display name instead. (Type.GetType()
with the full assembly display name will do the same thing, so that's fine,
also.)

Suzanne Cook
My .NET CLR Loader blog: http://blogs.gotdotnet.com/suzcook/

 

[Suzanne Cook [MS]]

Yes, you do need to give the full assembly display name (see
http://blogs.gotdotnet.com/suzcook/PermaLink.aspx/07954694-ac03-4459-80df-859a31cd76bc )
.. Wildcarding purposefully does not work because it causes dll hell (see
http://blogs.gotdotnet.com/suzcook/PermaLink.aspx/87646756-a94d-4c3a-a313-56c29a59b22d )
..

Suzanne Cook
My .NET CLR Loader blog: http://blogs.gotdotnet.com/suzcook/

 

[Scott Hodson]

What if I don't care what version of System.dll I want? I just want the
latest, most recent installed version of ADO.NET that is installed on
the machine, so the LoadPartial() (whatever the method is called)
suffices for my needs. And I understand the DLL hell problem.