By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,110 Members | 1,562 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,110 IT Pros & Developers. It's quick & easy.

Confused about reflection

P: n/a
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
Nov 16 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Try:

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

--
Sean Hederman

http://codingsanity.blogspot.com

"Rachel Suddeth" <ra****@bldhound.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
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

Nov 16 '05 #2

P: n/a
Rachel Suddeth wrote:
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
Nov 16 '05 #3

P: n/a
"Joakim Karlsson" <jk*******@NOSPAMjkarlsson.com> wrote in message
news:O9**************@tk2msftngp13.phx.gbl...
Rachel Suddeth wrote:

. . .


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
Nov 16 '05 #4

P: n/a
It works, it works, Hurray! (Thank you!)
-Rachel

"Rachel Suddeth" <ra****@bldhound.com> wrote in message
news:eO**************@TK2MSFTNGP14.phx.gbl...
"Joakim Karlsson" <jk*******@NOSPAMjkarlsson.com> wrote in message
news:O9**************@tk2msftngp13.phx.gbl...
Rachel Suddeth wrote:

. . .
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

Nov 16 '05 #5

P: n/a
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
Nov 16 '05 #6

P: n/a
More a standard setting called "late binding".


Nov 16 '05 #7

P: n/a
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.

"Cor Ligthert" <no************@planet.nl> wrote in message
news:uy**************@TK2MSFTNGP14.phx.gbl...
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

Nov 16 '05 #8

P: n/a
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" <us***@blogentry.com>
Newsgroups: microsoft.public.dotnet.languages.csharp
Sent: Sunday, January 09, 2005 1:05 PM
Subject: Re: Confused about reflection

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.

"Cor Ligthert" <no************@planet.nl> wrote in message
news:uy**************@TK2MSFTNGP14.phx.gbl...
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

"Sean Hederman" <us***@blogentry.com> wrote in message
news:cr**********@ctb-nnrp2.saix.net... 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.

"Cor Ligthert" <no************@planet.nl> wrote in message
news:uy**************@TK2MSFTNGP14.phx.gbl...
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


Nov 16 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.