Using interfaces for reflection-loaded classes

I am having problems with casting or converting a class to to an interface
from which it derives. I'm certain that it's due to how it's being loaded,
but I'm not sure how to get past the problem.

Here's a general outline of the architecture. It's oversimplified, but I
think it's enough info to help:

Assembly A.dll
{
interface IMyBase {}
}

Assembly B.dll (references A.dll)
{
class PlugIn : IMyBase {}
}

Assembly C.exe (references A.dll)
{
class InternalClass : IMyBase {}

class MyUI
{
// use IMyBase stuff here
}
}
Now if C.exe loads up an instance of InternalClass, it can cast it to
IMyBase and use it no problem.

If it loads B.dll and creates an instance of PlugIn through reflection I
*cannot* then cast it to an IMyBase.

How can I get access to the dynamically loaded plug in instance's members as
the base interface type? Til now I've been hacking it and just doing things
like getting functions by name, not by using the interface contract, but now
I need to create a handler for an event in the plug in and my hacks are
getting really ugly.

-Chris

[sloan]

I'm getting ready to leave for the day, but

http://sholliday.space s.live.com/Blog/cns!A68482B9628 A842A!126.entry
I have an example there.

But just to clarify, you saying that in B.dll
the following code fails
PlugIn pi = new PlugIn ();

IMyBase ipi = pi as IMyBase;

if(null!=ipi)
{
ipi.SomeMethod( );
}
?


"<ctacke/>" <ctacke[at]opennetcf[dot]comwrote in message
news:Ou******** ******@TK2MSFTN GP02.phx.gbl...

>I am having problems with casting or converting a class to to an interface
from which it derives. I'm certain that it's due to how it's being loaded,
but I'm not sure how to get past the problem.

Here's a general outline of the architecture. It's oversimplified, but I
think it's enough info to help:

Assembly A.dll
{
interface IMyBase {}
}

Assembly B.dll (references A.dll)
{
class PlugIn : IMyBase {}
}

Assembly C.exe (references A.dll)
{
class InternalClass : IMyBase {}

class MyUI
{
// use IMyBase stuff here
}
}
Now if C.exe loads up an instance of InternalClass, it can cast it to
IMyBase and use it no problem.

If it loads B.dll and creates an instance of PlugIn through reflection I
*cannot* then cast it to an IMyBase.

How can I get access to the dynamically loaded plug in instance's members
as the base interface type? Til now I've been hacking it and just doing
things like getting functions by name, not by using the interface
contract, but now I need to create a handler for an event in the plug in
and my hacks are getting really ugly.

-Chris

[Samuel R. Neff]

The oversimplified code works fine, assembly B can be loaded through
reflection (Assembly.LoadF ile for example) and then class PlugIn can
be cast directly to IMyBase.

So there has to be something different between the oversimplified case
and your actual code. I would suggest either building upon the
oversimplified case so it approaches your real code until it breaks
and seeing what caused the break, or working the other way and try to
comment out the real code until it works. Either way, we can't help
without knowing your code 'cause the sample you provided works fine.

Besides this oversimplified example, we use this type of reflection
loaded plugin system extensively in our applications and have not had
a problem casting instances to their interfaces.

HTH,

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Tue, 25 Sep 2007 16:17:08 -0500, "<ctacke/>"
<ctacke[at]opennetcf[dot]comwrote:

>I am having problems with casting or converting a class to to an interface
from which it derives. I'm certain that it's due to how it's being loaded,
but I'm not sure how to get past the problem.

Here's a general outline of the architecture. It's oversimplified, but I
think it's enough info to help:

Assembly A.dll
{
interface IMyBase {}
}

Assembly B.dll (references A.dll)
{
class PlugIn : IMyBase {}
}

Assembly C.exe (references A.dll)
{
class InternalClass : IMyBase {}

class MyUI
{
// use IMyBase stuff here
}
}
Now if C.exe loads up an instance of InternalClass, it can cast it to
IMyBase and use it no problem.

If it loads B.dll and creates an instance of PlugIn through reflection I
*cannot* then cast it to an IMyBase.

How can I get access to the dynamically loaded plug in instance's members as
the base interface type? Til now I've been hacking it and just doing things
like getting functions by name, not by using the interface contract, but now
I need to create a handler for an event in the plug in and my hacks are
getting really ugly.

-Chris

I'll look at it further tomorrow, but the "more true" scenario is this:

We have an app (C) that gets the interface from a separate assembly (A).
We have a plug in (B) that also gets the interface from A.

The app loads a class from the plug in. This class exposes a "GetForm"
method. The Form returned from this inherits Form plus implements IPlugIn.
It can be used as a Form, as we're able to display it just fine, however it
just doesn't like that interface. I can get the interface by name, so the
class definitely implements it, but it won't cast. It's like it sees it as
a separate interface, just with coincidentally the same interface name.

-Chris

"Samuel R. Neff" <sa********@nom ail.comwrote in message
news:09******** *************** *********@4ax.c om...

>
The oversimplified code works fine, assembly B can be loaded through
reflection (Assembly.LoadF ile for example) and then class PlugIn can
be cast directly to IMyBase.

So there has to be something different between the oversimplified case
and your actual code. I would suggest either building upon the
oversimplified case so it approaches your real code until it breaks
and seeing what caused the break, or working the other way and try to
comment out the real code until it works. Either way, we can't help
without knowing your code 'cause the sample you provided works fine.

Besides this oversimplified example, we use this type of reflection
loaded plugin system extensively in our applications and have not had
a problem casting instances to their interfaces.

HTH,

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Tue, 25 Sep 2007 16:17:08 -0500, "<ctacke/>"
<ctacke[at]opennetcf[dot]comwrote:

>>I am having problems with casting or converting a class to to an interface
from which it derives. I'm certain that it's due to how it's being
loaded,
but I'm not sure how to get past the problem.

Here's a general outline of the architecture. It's oversimplified, but I
think it's enough info to help:

Assembly A.dll
{
interface IMyBase {}
}

Assembly B.dll (references A.dll)
{
class PlugIn : IMyBase {}
}

Assembly C.exe (references A.dll)
{
class InternalClass : IMyBase {}

class MyUI
{
// use IMyBase stuff here
}
}
Now if C.exe loads up an instance of InternalClass, it can cast it to
IMyBase and use it no problem.

If it loads B.dll and creates an instance of PlugIn through reflection I
*cannot* then cast it to an IMyBase.

How can I get access to the dynamically loaded plug in instance's members
as
the base interface type? Til now I've been hacking it and just doing
things
like getting functions by name, not by using the interface contract, but
now
I need to create a handler for an event in the plug in and my hacks are
getting really ugly.

-Chris

[Peter Duniho]

<ctacke/wrote:

I'll look at it further tomorrow, but the "more true" scenario is this:

We have an app (C) that gets the interface from a separate assembly (A).
We have a plug in (B) that also gets the interface from A.

The app loads a class from the plug in. This class exposes a "GetForm"
method. The Form returned from this inherits Form plus implements IPlugIn.
It can be used as a Form, as we're able to display it just fine, however it
just doesn't like that interface. I can get the interface by name, so the
class definitely implements it, but it won't cast. It's like it sees it as
a separate interface, just with coincidentally the same interface name.

I really have no practical experience with this sort of thing. However,
the last time something like this came up in this newsgroup, it turned
out to be an issue where the class being used for the cast was just as
you describe: it had the same name, but was from a completely different
assembly.

You should double-check to make sure that the interface that all code is
using is the same interface. That is, all of the code referencing the
interface uses the same assembly, compiled from a single source. The
problem _sounds_ like you may have an issue where you're getting the
interface from multiple places.

Pete

[sloan]

I concur.

I've seen that issue as well, where it was the same name, but actually
different classes.

Can you get some extra info about it , using something like ... GetType()
and the full AssemblyName or something like that
(its late and I'm going from memory)


"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:13******** *****@corp.supe rnews.com...

<ctacke/wrote:

>I'll look at it further tomorrow, but the "more true" scenario is this:

We have an app (C) that gets the interface from a separate assembly (A).
We have a plug in (B) that also gets the interface from A.

The app loads a class from the plug in. This class exposes a "GetForm"
method. The Form returned from this inherits Form plus implements
IPlugIn. It can be used as a Form, as we're able to display it just fine,
however it just doesn't like that interface. I can get the interface by
name, so the class definitely implements it, but it won't cast. It's
like it sees it as a separate interface, just with coincidentally the
same interface name.

I really have no practical experience with this sort of thing. However,
the last time something like this came up in this newsgroup, it turned out
to be an issue where the class being used for the cast was just as you
describe: it had the same name, but was from a completely different
assembly.

You should double-check to make sure that the interface that all code is
using is the same interface. That is, all of the code referencing the
interface uses the same assembly, compiled from a single source. The
problem _sounds_ like you may have an issue where you're getting the
interface from multiple places.

Pete