Hi,

[ BTW I'm using C# ]

I'm trying to implement a Plugin architecture where I have a single UI
framework, and then load dll components into that framework.

At the moment I'm constructing the Plugin loading mechanism, I've created a
plugin interface ( that the plugin clients must implement ) and a pluginhost
interface ( thart the ui framework plugin manager must imlpement ).

When the UI framework loads the plugin assembly it checks the types in the
assembly to ensure it supports the plugin interface, if it does then it
constructs an instance of this type and casts it to the plugin interface type.

If I create a source file with these interfaces in and link this file ( i.e.
share the file )into each project then I get a CastException - in
CreatePluginInstance - when I cast to the plugin interface type. If I
implement this interface in a separate dll and then reference this in the
framework and the pluginclient, then the cast succeeds.

I suppose this works, but I would rather keep the number of dlls to a
minimum, and hoped to be able to get away with just sharing the interface
source file. Is this possible ??, or do I need to implement it this way ??

regards
Rich.


CODE:

Interface.....

namespace PluginInterface
{
public interface IPlugin
{
IPluginHost Host{ get;set; }
}

public interface IPluginHost
{
bool Register(IPlugin ipi);
}
}


PluginCreation and Cast...

Assembly objAssembly = Assembly.LoadFrom(_strPath);

foreach (Type iterTypes in objAssembly.GetTypes())
{
foreach (Type iterInterfaces in
objIterGetAssemblyTypes.GetInterfaces())
{
if
(iterInterfaces.Equals(typeof(PluginInterface.IPlugin)))
{
CreatePluginInstance(iterInterfaces);
}
}
}
}

public void CreatePluginInstance( Type _assemblyType )
{
PluginInterface.IPlugin sui_Plugin =
(PluginInterface.IPlugin)Activator.CreateInstance(_assemblyType);
}

Re: Plugin Architecture Problem by David

David
Thu Jan 27 04:41:35 CST 2005

You can define the interface in a single assembly but you need to manage how
many copies of it are floating around. What's probably happening is that
plugin A is using a local copy of the interface assembly and the client is
using its own copy of the interface assembly. Even if both define the exact
same type the CLR will treat them as two completely different types because
they are housed in different assemblies.

For simplicity I would put the interface assembly in the same directory as
the client (the directory where appdomain's appbase is pointed at) and not
put any other copies where the plugins will try to load them.



"RichS" <RichS@discussions.microsoft.com> wrote in message
news:BC2C50B1-3FC0-4CCF-A722-2B015D629848@microsoft.com...
> Hi,
>
> [ BTW I'm using C# ]
>
> I'm trying to implement a Plugin architecture where I have a single UI
> framework, and then load dll components into that framework.
>
> At the moment I'm constructing the Plugin loading mechanism, I've created
> a
> plugin interface ( that the plugin clients must implement ) and a
> pluginhost
> interface ( thart the ui framework plugin manager must imlpement ).
>
> When the UI framework loads the plugin assembly it checks the types in the
> assembly to ensure it supports the plugin interface, if it does then it
> constructs an instance of this type and casts it to the plugin interface
> type.
>
> If I create a source file with these interfaces in and link this file (
> i.e.
> share the file )into each project then I get a CastException - in
> CreatePluginInstance - when I cast to the plugin interface type. If I
> implement this interface in a separate dll and then reference this in the
> framework and the pluginclient, then the cast succeeds.
>
> I suppose this works, but I would rather keep the number of dlls to a
> minimum, and hoped to be able to get away with just sharing the interface
> source file. Is this possible ??, or do I need to implement it this way
> ??
>
> regards
> Rich.
>
>
> CODE:
>
> Interface.....
>
> namespace PluginInterface
> {
> public interface IPlugin
> {
> IPluginHost Host{ get;set; }
> }
>
> public interface IPluginHost
> {
> bool Register(IPlugin ipi);
> }
> }
>
>
> PluginCreation and Cast...
>
> Assembly objAssembly = Assembly.LoadFrom(_strPath);
>
> foreach (Type iterTypes in objAssembly.GetTypes())
> {
> foreach (Type iterInterfaces in
> objIterGetAssemblyTypes.GetInterfaces())
> {
> if
> (iterInterfaces.Equals(typeof(PluginInterface.IPlugin)))
> {
> CreatePluginInstance(iterInterfaces);
> }
> }
> }
> }
>
> public void CreatePluginInstance( Type _assemblyType )
> {
> PluginInterface.IPlugin sui_Plugin =
> (PluginInterface.IPlugin)Activator.CreateInstance(_assemblyType);
> }
>
>
>
>
>



Re: Plugin Architecture Problem by RichS

RichS
Thu Jan 27 04:59:04 CST 2005

Sorry, I think I've confused you.

I was hoping that my plugin interface source file could be shared across my
plugin manager ( framework ) assembly and my plugin assemblies - rather than
having to have an intermediate plugin interface assembly.

Now because I want the plugin manager to get an instance of the plugin
object that I get through the plugin interface I also need to define this in
my intemediate plugin interface assembly. It feels a bit messy, but not sure
if I can get around it as I understand your comment that the CLR will treat
classes different if they were created in different assemblies even if they
are from the same shared source file - hence I cannot cast between the share
source file class compiled in assembly 1 to the same share source file class
compiled in assembly 2.

Maybe I need to look at this again, as it feels a bit messy - try and reduce
a bit of the clutter.

Rich.

"David Levine" wrote:

> You can define the interface in a single assembly but you need to manage how
> many copies of it are floating around. What's probably happening is that
> plugin A is using a local copy of the interface assembly and the client is
> using its own copy of the interface assembly. Even if both define the exact
> same type the CLR will treat them as two completely different types because
> they are housed in different assemblies.
>
> For simplicity I would put the interface assembly in the same directory as
> the client (the directory where appdomain's appbase is pointed at) and not
> put any other copies where the plugins will try to load them.
>
>
>
> "RichS" <RichS@discussions.microsoft.com> wrote in message
> news:BC2C50B1-3FC0-4CCF-A722-2B015D629848@microsoft.com...
> > Hi,
> >
> > [ BTW I'm using C# ]
> >
> > I'm trying to implement a Plugin architecture where I have a single UI
> > framework, and then load dll components into that framework.
> >
> > At the moment I'm constructing the Plugin loading mechanism, I've created
> > a
> > plugin interface ( that the plugin clients must implement ) and a
> > pluginhost
> > interface ( thart the ui framework plugin manager must imlpement ).
> >
> > When the UI framework loads the plugin assembly it checks the types in the
> > assembly to ensure it supports the plugin interface, if it does then it
> > constructs an instance of this type and casts it to the plugin interface
> > type.
> >
> > If I create a source file with these interfaces in and link this file (
> > i.e.
> > share the file )into each project then I get a CastException - in
> > CreatePluginInstance - when I cast to the plugin interface type. If I
> > implement this interface in a separate dll and then reference this in the
> > framework and the pluginclient, then the cast succeeds.
> >
> > I suppose this works, but I would rather keep the number of dlls to a
> > minimum, and hoped to be able to get away with just sharing the interface
> > source file. Is this possible ??, or do I need to implement it this way
> > ??
> >
> > regards
> > Rich.
> >
> >
> > CODE:
> >
> > Interface.....
> >
> > namespace PluginInterface
> > {
> > public interface IPlugin
> > {
> > IPluginHost Host{ get;set; }
> > }
> >
> > public interface IPluginHost
> > {
> > bool Register(IPlugin ipi);
> > }
> > }
> >
> >
> > PluginCreation and Cast...
> >
> > Assembly objAssembly = Assembly.LoadFrom(_strPath);
> >
> > foreach (Type iterTypes in objAssembly.GetTypes())
> > {
> > foreach (Type iterInterfaces in
> > objIterGetAssemblyTypes.GetInterfaces())
> > {
> > if
> > (iterInterfaces.Equals(typeof(PluginInterface.IPlugin)))
> > {
> > CreatePluginInstance(iterInterfaces);
> > }
> > }
> > }
> > }
> >
> > public void CreatePluginInstance( Type _assemblyType )
> > {
> > PluginInterface.IPlugin sui_Plugin =
> > (PluginInterface.IPlugin)Activator.CreateInstance(_assemblyType);
> > }
> >
> >
> >
> >
> >
>
>
>

Re: Plugin Architecture Problem by Sean

Sean
Thu Jan 27 06:33:04 CST 2005

"RichS" <RichS@discussions.microsoft.com> wrote in message
news:619E6F3C-A0D8-424A-B928-B8B7CE8CAABD@microsoft.com...
> Sorry, I think I've confused you.
>
> I was hoping that my plugin interface source file could be shared across
> my
> plugin manager ( framework ) assembly and my plugin assemblies - rather
> than
> having to have an intermediate plugin interface assembly.

When you share a source file across multiple assemblies, .NET regards the
types as being different. This is because a types classification is partly
made up by the assembly. Therefore, if class MyClass (in MyClass.cs) is
included into assembly A and assembly B, then .NET sees "MyClass, A" and
"MyClass, B" as the type names (I've simplified this a bit), and therefore
concludes that they are different types.

> Now because I want the plugin manager to get an instance of the plugin
> object that I get through the plugin interface I also need to define this
> in
> my intemediate plugin interface assembly. It feels a bit messy, but not
> sure
> if I can get around it as I understand your comment that the CLR will
> treat
> classes different if they were created in different assemblies even if
> they
> are from the same shared source file - hence I cannot cast between the
> share
> source file class compiled in assembly 1 to the same share source file
> class
> compiled in assembly 2.

You could have one "master" assembly that contains your shared type
interfaces as well as you default implementation of the host interfaces.
Then, the client assembly would reference this master assembly in order to
implement it's types. In addition, anyone wanting to provide their own host
interfaces could also reference this assembly, and pick and choose which of
your implementation classes (if any) to use. This would cut things down from
3 assemblies to 2. Following the same scenario, your default client class
implementations could also be included into the master assembly. Then, for
the default system, only one assembly would be required.

> Maybe I need to look at this again, as it feels a bit messy - try and
> reduce
> a bit of the clutter.
[snipped]

--
Sean Hederman

http://codingsanity.blogspot.com



Re: Plugin Architecture Problem by RichS

RichS
Thu Jan 27 07:21:06 CST 2005

Excellent, thanks.

"Sean Hederman" wrote:

> "RichS" <RichS@discussions.microsoft.com> wrote in message
> news:619E6F3C-A0D8-424A-B928-B8B7CE8CAABD@microsoft.com...
> > Sorry, I think I've confused you.
> >
> > I was hoping that my plugin interface source file could be shared across
> > my
> > plugin manager ( framework ) assembly and my plugin assemblies - rather
> > than
> > having to have an intermediate plugin interface assembly.
>
> When you share a source file across multiple assemblies, .NET regards the
> types as being different. This is because a types classification is partly
> made up by the assembly. Therefore, if class MyClass (in MyClass.cs) is
> included into assembly A and assembly B, then .NET sees "MyClass, A" and
> "MyClass, B" as the type names (I've simplified this a bit), and therefore
> concludes that they are different types.
>
> > Now because I want the plugin manager to get an instance of the plugin
> > object that I get through the plugin interface I also need to define this
> > in
> > my intemediate plugin interface assembly. It feels a bit messy, but not
> > sure
> > if I can get around it as I understand your comment that the CLR will
> > treat
> > classes different if they were created in different assemblies even if
> > they
> > are from the same shared source file - hence I cannot cast between the
> > share
> > source file class compiled in assembly 1 to the same share source file
> > class
> > compiled in assembly 2.
>
> You could have one "master" assembly that contains your shared type
> interfaces as well as you default implementation of the host interfaces.
> Then, the client assembly would reference this master assembly in order to
> implement it's types. In addition, anyone wanting to provide their own host
> interfaces could also reference this assembly, and pick and choose which of
> your implementation classes (if any) to use. This would cut things down from
> 3 assemblies to 2. Following the same scenario, your default client class
> implementations could also be included into the master assembly. Then, for
> the default system, only one assembly would be required.
>
> > Maybe I need to look at this again, as it feels a bit messy - try and
> > reduce
> > a bit of the clutter.
> [snipped]
>
> --
> Sean Hederman
>
> http://codingsanity.blogspot.com
>
>
>

Re: Plugin Architecture Problem by RichS

RichS
Thu Jan 27 07:23:02 CST 2005

Excellent, thanks.

"Sean Hederman" wrote:

> "RichS" <RichS@discussions.microsoft.com> wrote in message
> news:619E6F3C-A0D8-424A-B928-B8B7CE8CAABD@microsoft.com...
> > Sorry, I think I've confused you.
> >
> > I was hoping that my plugin interface source file could be shared across
> > my
> > plugin manager ( framework ) assembly and my plugin assemblies - rather
> > than
> > having to have an intermediate plugin interface assembly.
>
> When you share a source file across multiple assemblies, .NET regards the
> types as being different. This is because a types classification is partly
> made up by the assembly. Therefore, if class MyClass (in MyClass.cs) is
> included into assembly A and assembly B, then .NET sees "MyClass, A" and
> "MyClass, B" as the type names (I've simplified this a bit), and therefore
> concludes that they are different types.
>
> > Now because I want the plugin manager to get an instance of the plugin
> > object that I get through the plugin interface I also need to define this
> > in
> > my intemediate plugin interface assembly. It feels a bit messy, but not
> > sure
> > if I can get around it as I understand your comment that the CLR will
> > treat
> > classes different if they were created in different assemblies even if
> > they
> > are from the same shared source file - hence I cannot cast between the
> > share
> > source file class compiled in assembly 1 to the same share source file
> > class
> > compiled in assembly 2.
>
> You could have one "master" assembly that contains your shared type
> interfaces as well as you default implementation of the host interfaces.
> Then, the client assembly would reference this master assembly in order to
> implement it's types. In addition, anyone wanting to provide their own host
> interfaces could also reference this assembly, and pick and choose which of
> your implementation classes (if any) to use. This would cut things down from
> 3 assemblies to 2. Following the same scenario, your default client class
> implementations could also be included into the master assembly. Then, for
> the default system, only one assembly would be required.
>
> > Maybe I need to look at this again, as it feels a bit messy - try and
> > reduce
> > a bit of the clutter.
> [snipped]
>
> --
> Sean Hederman
>
> http://codingsanity.blogspot.com
>
>
>