Re: Casting 'object' to "real/useful" Type

[Robert]

Thanks George, I really am grateful for attempts to be helpful, but this
really doesn't answer the question in my OP.

What I am looking for is an explanation of WHY things are this way (I was
not looking for a work-around).

Again, I am appreciative of the feedback. I will note, that even though I
can use Interfaces, the calling application and the dynamically loaded
assembly both need compile-time refrences to the assembly that contains the
interfaces (as you accurately pointed out). This does not answer the core
question I have about the need to have compile-time references.

Again, the question is all about an explanation of WHY we must have
compile-time references... and why Reflection cannot get us around that
apparent requrement.

-Robert

[Jon Skeet [C# MVP]]

Robert <[e-mail]:

Thanks George, I really am grateful for attempts to be helpful, but this
really doesn't answer the question in my OP.

What I am looking for is an explanation of WHY things are this way (I was
not looking for a work-around).

Again, I am appreciative of the feedback. I will note, that even though I
can use Interfaces, the calling application and the dynamically loaded
assembly both need compile-time refrences to the assembly that contains the
interfaces (as you accurately pointed out). This does not answer the core
question I have about the need to have compile-time references.

Again, the question is all about an explanation of WHY we must have
compile-time references... and why Reflection cannot get us around that
apparent requrement.

If you're willing to make *all* the calls via reflection, then you can
indeed work completely without any other references.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[sloan]

You must have a compile time reference TO THE INTERFACE.
This is why the interface library should be stand alone...and you can put
the concrete's anywhere you'd like.

If you follow my example, it will show you ( I believe ) a non compile time
reference.

.....

as my example shows:

<rateQuoterObject enabled="true"
assemblyName="GranadaCoder.Applications.FactoryPat ternExamples.ConcreteObjectsOutsideBaseAssembly"
className="GranadaCoder.Applications.FactoryPatter nExamples.ConcreteObjectsOutsideBaseAssembly.Concr eteRateQuoters.UPSRateQuoter"
ShippingCompanyHomeState="NC"/>

I have a "Quoter" that isn't referenced. Or at least, doesn't need to be
referenced.

...
DotNet has to know ~at least~ about the interface if you want it to return
something other than object.

"Robert" <[e-mail] in message
news:Oo**************@TK2MSFTNGP05.phx.gbl...

Thanks George, I really am grateful for attempts to be helpful, but this
really doesn't answer the question in my OP.

What I am looking for is an explanation of WHY things are this way (I was
not looking for a work-around).

Again, I am appreciative of the feedback. I will note, that even though I
can use Interfaces, the calling application and the dynamically loaded
assembly both need compile-time refrences to the assembly that contains
the interfaces (as you accurately pointed out). This does not answer the
core question I have about the need to have compile-time references.

Again, the question is all about an explanation of WHY we must have
compile-time references... and why Reflection cannot get us around that
apparent requrement.

-Robert

[Ignacio Machin ( .NET/ C# MVP )]

On Apr 22, 2:26*pm, "Robert" <[e-mail]:

Thanks George, I really am grateful for attempts to be helpful, but this
really doesn't answer the question in my OP.

What I am looking for is an explanation of WHY things are this way (I was
not looking for a work-around).

Again, I am appreciative of the feedback. I will note, that even though I
can use Interfaces, the calling application and the dynamically loaded
assembly both need compile-time refrences to the assembly that contains the
interfaces (as you accurately pointed out). This does not answer the core
question I have about the need to have compile-time references.

Again, the question is all about an explanation of WHY we must have
compile-time references... and why Reflection cannot get us around that
apparent requrement.

-Robert

Hi,

You do not need add a refeence at compile time if you load all your
dlls using Assembly.Load() and call members using reflection.
It's a slow and convoluted way of doing it, but you can do it.

[=?Utf-8?B?YnJ1Y2UgYmFya2Vy?=]

its because the .net runtime is strongly typed. to call a method or access a
property, the type of the object must be known at compile time. the major
workaround is as suggested using interfaces.

other languages (javascript, ruby, python, object-c, smalltalk, etc) support
dynamic binding, which allows your code to just call the method.

even java (which is also strongly typed) supports runtime re-compiles so
that plugins and remoting will work the way you expect. this feature was left
out of .net for various performance reasons.

..net now has a dlr (dynamic language runtime) that supports this behavior,
but you need to use a dlr language like IronPython, IronRuby or managed
JScript.
-- bruce (sqlwork.com)
"Robert" wrote:

Thanks George, I really am grateful for attempts to be helpful, but this
really doesn't answer the question in my OP.

What I am looking for is an explanation of WHY things are this way (I was
not looking for a work-around).

Again, I am appreciative of the feedback. I will note, that even though I
can use Interfaces, the calling application and the dynamically loaded
assembly both need compile-time refrences to the assembly that contains the
interfaces (as you accurately pointed out). This does not answer the core
question I have about the need to have compile-time references.

Again, the question is all about an explanation of WHY we must have
compile-time references... and why Reflection cannot get us around that
apparent requrement.

-Robert

[Robert]

Thank you Bruce for answering my specific question. I have a Quick followup
question:

Is it true then [given your response] that I _cannot_ do step 3 of the
following sequence from my C# application:

1. load an .NET assembly via Reflection - where my application has
absolutely no compile-time knowledge of the assembly or the types within
that assembly (i.e., no project reference to the assembly). This step, by
itself, is obviously easy to do using Reflection.

2. use Reflection to identify the types within that assembly. This step, by
itself, is obviously easy to do using Reflection.

3. instantiate a class of a specific type from within that assembly. This
step, given steps 1 and 2 above cannot happen, and for the reasons you
gave - yes?

For example, MyApp is a C# app that loads the Some3rdParty assembly, which
is a .NET assembly that contains a class named Frapper. Apparently because
the .NET runtime is strongly typed, MyApp _cannot_ create a Frapper instance
_unless_ MyApp also has a compile-time reference to the Some3rdParty
assembly. Is this correct, and for the reasons you stated?

I'm asking this because I want to verify that I understand your response.

Please note that I'm not asking about the merits of doing this, and I'm not
attempting to solve some problem "the hard way". My interest is mostly
academic... just wanting to understand things more clearly, and particularly
to find out if my understanding is incorrect. FWIW, I have already done a
couple of plug-in apps that go with the interface-based recommendations
others have made elsewhere in this thread. I'm clear on that... I just want
to know why, and I think I do now - provided that I understand your
response.

Thanks.

"bruce barker" <br*********@discussions.microsoft.comwrote in message
news:3C**********************************@microsof t.com...

its because the .net runtime is strongly typed. to call a method or access
a
property, the type of the object must be known at compile time. the major
workaround is as suggested using interfaces.

other languages (javascript, ruby, python, object-c, smalltalk, etc)
support
dynamic binding, which allows your code to just call the method.

even java (which is also strongly typed) supports runtime re-compiles so
that plugins and remoting will work the way you expect. this feature was
left
out of .net for various performance reasons.

.net now has a dlr (dynamic language runtime) that supports this behavior,
but you need to use a dlr language like IronPython, IronRuby or managed
JScript.
-- bruce (sqlwork.com)
"Robert" wrote:

>Thanks George, I really am grateful for attempts to be helpful, but this
really doesn't answer the question in my OP.

What I am looking for is an explanation of WHY things are this way (I was
not looking for a work-around).

Again, I am appreciative of the feedback. I will note, that even though I
can use Interfaces, the calling application and the dynamically loaded
assembly both need compile-time refrences to the assembly that contains
the
interfaces (as you accurately pointed out). This does not answer the core
question I have about the need to have compile-time references.

Again, the question is all about an explanation of WHY we must have
compile-time references... and why Reflection cannot get us around that
apparent requrement.

-Robert

[Gilles Kohl [MVP]]

Robert,

On Tue, 22 Apr 2008 13:38:50 -0700, "Robert" <[e-mail]:

>Thank you Bruce for answering my specific question. I have a Quick followup
question:

Is it true then [given your response] that I _cannot_ do step 3 of the
following sequence from my C# application:

1. load an .NET assembly via Reflection - where my application has
absolutely no compile-time knowledge of the assembly or the types within
that assembly (i.e., no project reference to the assembly). This step, by
itself, is obviously easy to do using Reflection.

2. use Reflection to identify the types within that assembly. This step, by
itself, is obviously easy to do using Reflection.

3. instantiate a class of a specific type from within that assembly. This
step, given steps 1 and 2 above cannot happen, and for the reasons you
gave - yes?

For example, MyApp is a C# app that loads the Some3rdParty assembly, which
is a .NET assembly that contains a class named Frapper. Apparently because
the .NET runtime is strongly typed, MyApp _cannot_ create a Frapper instance
_unless_ MyApp also has a compile-time reference to the Some3rdParty
assembly. Is this correct, and for the reasons you stated?

No - consider this sample MyApp:

namespace MyApp
{
class Program
{
static void Main(string[] args)
{
Assembly assembly =
Assembly.LoadFrom(@"c:\tmp\Some3rdParty\bin\Debug\ Some3rdParty.dll");

Type frapperType = assembly.GetTypes().Where(t =t.Name ==
"Frapper").SingleOrDefault();

if(frapperType == null)
{
Console.WriteLine("Out of frappers");
return;
}

MethodInfo frappitMethod = frapperType.GetMethods().Where(m
=m.Name == "Frappit").SingleOrDefault();
if(frappitMethod == null)
{
Console.WriteLine("Frapper can't frap it");
return;
}

object frapperInstance =
Activator.CreateInstance(frapperType);
string result = (string)frappitMethod.Invoke(frapperInstance,
new object[0]);

Console.WriteLine(result);
}
}
}

it will attempt to load "Some3rdParty.dll", find any class called
"Frapper", locate a method "Frappit" in that class (which hopefully
returns a string and doesn't have any parameters), and call it.

Here's Frapper

namespace Some3rdParty
{
public class Frapper
{
public string Frappit()
{
return "Greetings, Pr. Falken";
}
}
}

This works without any reference from the MyApp project to the
Some3rdParty project containing the Frapper class.

Regards,
Gilles.

[Robert]

<Snip>

Thank you Gilles. Apparently my understanding was incorrect. It really helps
to see and study the sample code that you so kindly provided.

-Robert