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

Try:

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

--
Sean Hederman

http://codingsanity.blogspot.com

"Rachel Suddeth" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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
>
>

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

"Joakim Karlsson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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

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

"Rachel Suddeth" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Joakim Karlsson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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
>
>

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

More a standard setting called "late binding".

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>

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" <(E-Mail Removed)>
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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
news:crrva6$ha7$(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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
>>
>
>