Confused about reflection

[Rachel Suddeth]

I'm trying to use reflection to create an object at runtime where the type
is given by a string. I thought we should be able to do that, but so far
it's not working. I'm trying to work on reproducing the scenario in a
simpler way, but it's slow going, and maybe there is something very basic I
don't know yet....

Given the following lines of code:
-------------
CredLookup testLU = new CredLookup();
string sLUType = testLU.GetType().ToString();
Type typLU = Type.GetType(sLUType);
------------
I would have thought "typeLU" would end up being the same as
"testLU.GetType()". In fact, when I had a similar type defined in the same
assembly (same NameSpace) with similar test code (just replace "CredLookup"
with "MLookup", it worked as expected. But with this new type in a different
assembly, Type.GetType() returns null. So if I give it the type at compile
time, it recognizes the type and runs just fine. But at run time, can't find
it. Anyone have an idea why that would happen?

Rachel

 

[Sean Hederman]

Try:

CredLookup testLU = new CredLookup();
string sLUType = testLU.GetType().AssemblyQualifiedName;
Type typLU = Type.GetType(sLUType);

 

[Joakim Karlsson]

I'm trying to use reflection to create an object at runtime where the type
is given by a string. I thought we should be able to do that, but so far
it's not working. I'm trying to work on reproducing the scenario in a
simpler way, but it's slow going, and maybe there is something very basic I
don't know yet....

Given the following lines of code:
-------------
CredLookup testLU = new CredLookup();
string sLUType = testLU.GetType().ToString();
Type typLU = Type.GetType(sLUType);
------------
I would have thought "typeLU" would end up being the same as
"testLU.GetType()". In fact, when I had a similar type defined in the same
assembly (same NameSpace) with similar test code (just replace "CredLookup"
with "MLookup", it worked as expected. But with this new type in a different
assembly, Type.GetType() returns null. So if I give it the type at compile
time, it recognizes the type and runs just fine. But at run time, can't find
it. Anyone have an idea why that would happen?

Rachel

If you want to get a hold of a type that resides in another assembly by
it's name, you need to full qualify it with the assembly name.

string typeName = "Namespace.Class, AssemblyName";

/Joakim

 

[Rachel Suddeth]

If you want to get a hold of a type that resides in another assembly by
it's name, you need to full qualify it with the assembly name.

string typeName = "Namespace.Class, AssemblyName";

/Joakim

Thank you so much (to both respondants.) Exactly what I needed. I just spent
2 hours reading about reflection, and never saw a mention of
AssemblyQualifiedName. Need to add a ", AssemblyName". I trust I'll be able
to figure out what the AssemblyName is...

Rachel

 

[Rachel Suddeth]

It works, it works, Hurray! (Thank you!)
-Rachel

Thank you so much (to both respondants.) Exactly what I needed. I just spent
2 hours reading about reflection, and never saw a mention of
AssemblyQualifiedName. Need to add a ", AssemblyName". I trust I'll be able
to figure out what the AssemblyName is...

Rachel

 

[Cor Ligthert]

Rachel,

You know that you are now using C# are implementing what is called a bad
possibility of VBNet?

Just to tell you, for when you did not know that, nothing more.

Cor

 

[Cor Ligthert]

More a standard setting called "late binding".

 

[Sean Hederman]

Not neccesarily, since we don't know what Rachel's doing with this
dynamically created object. If she's calling it's methods through
Reflection, then yes it is late binding, and it'd probably be better to use
VB. However, if she's assigning it to a compatible type (e.g. an interface),
and then calling methods on that type, then it's still early binding, even
though the creation is "late bound". This kind of approach is often used in
plugin architectures.

As for late binding being "bad", I personally don't always agree with that.
Late binding is significantly slower than early binding, since you need to
go through the Reflection API. In addition, any invalid invocations will
only be picked up at run time instead of compile time. These two problems do
suggest great caution in using it, but sometimes it can be neccesary. In
such situations, I personally prefer using VB.NET, since the code looks
cleaner. All that said, it's very rare that I've found it neccessary.

 

[Rachel Suddeth]

Thanks both of you. I was not aware, and I am new to Windows programming in
general in the last several months. That is, this is the first time I've
done any real production Windows code, so warnings are helpful.

Essentially what I have is the thing that Sean says isn't really late
binding. I've got a contol with a button on it. The button click
creates_and_opens or closes_and_disposes a form. (The form is the thing of
unknown type that we are creating.) And there is a property that tells which
kind of form -- which is really an enumeration value of all compatible form
types, so as long as the enum is set up correctly, we really do get compile
time (or actually earlier) checking, not to mention some nifty designer
support. Then there is a private (actually protected) member of the control
of a type that is the base for all eligible forms. The base form has
OpenLookup() and CloseLookup() methods which are the only methods the
control needs to call -- other than the constructor, which we get via
reflection.

We aren't experienced at GUI programming, but we think this is a rather
clever design, and I'm kind of thrilled with things like the designer giving
us neato support on the enum, the enum having a ToString() method, and the
framework having a way to map the string to a type. We expect to have 20+ of
these forms used in > 100 different places in our ap, with new forms and
controls of this sort being added quite regularly in future, so it was
important to us to encapsulate as much of the commonalities as possible in a
way that would be convenient to program.

-Rachel

----- Original Message -----
From: "Sean Hederman" <[email protected]>
Newsgroups: microsoft.public.dotnet.languages.csharp
Sent: Sunday, January 09, 2005 1:05 PM
Subject: Re: Confused about reflection