Prev: delegate vs condition check
Next: Problem with TTable
From: Shalom Shachne on 29 Jun 2010 16:16
We have been trying to mimic a sort of "plug-in" design with our
app. We are loading assemblies which are in the app's assembly
directory and then iterating all the Types in each Assembly to find
ones which match the plug-in loaders designated type.

I was thinking of perhaps trying to use Assembly Attributes to mark
the plugin Assembly(ies) so that we don't bother iterating the types
from other assemblies which we know wouldn't contain the "plugin".

It seems like there is a Product Info Assembly Attribute, that maybe
could be used for this purpose.

I'm not totally sure that this is a necessary or good idea. It seems
to iterate all the other assembly's types very quickly - so maybe this
is an unecessary optimization.

I would welcome any thoughts or suggestions.
From: Peter Duniho on 29 Jun 2010 22:55
Shalom Shachne wrote:
> We have been trying to mimic a sort of "plug-in" design with our
> app. We are loading assemblies which are in the app's assembly
> directory and then iterating all the Types in each Assembly to find
> ones which match the plug-in loaders designated type.
>
> I was thinking of perhaps trying to use Assembly Attributes to mark
> the plugin Assembly(ies) so that we don't bother iterating the types
> from other assemblies which we know wouldn't contain the "plugin".
>
> It seems like there is a Product Info Assembly Attribute, that maybe
> could be used for this purpose.
>
> I'm not totally sure that this is a necessary or good idea. It seems
> to iterate all the other assembly's types very quickly - so maybe this
> is an unecessary optimization.
>
> I would welcome any thoughts or suggestions.

AFAIK, the hard (i.e. slow) part is loading the assembly. So if you
have to load the assembly just to inspect the attribute, that's probably
not significantly better than just iterating over the types in the assembly.

If you do choose to use an attribute, I would implement your own
attribute specifically for the purpose, rather than reusing an existing one.

Pete
From: Jeff Johnson on 30 Jun 2010 11:28
"Peter Duniho" <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote in message
news:_-ednfFrO7SXL7fRnZ2dnUVZ_jKdnZ2d(a)posted.palinacquisition...

> AFAIK, the hard (i.e. slow) part is loading the assembly. So if you have
> to load the assembly just to inspect the attribute, that's probably not
> significantly better than just iterating over the types in the assembly.

Perhaps this would be where you'd want to use the ReflectionOnlyLoad[From]()
method.

> If you do choose to use an attribute, I would implement your own attribute
> specifically for the purpose, rather than reusing an existing one.

Agreed.


From: Peter Duniho on 30 Jun 2010 11:34
Jeff Johnson wrote:
> "Peter Duniho" <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote in message
> news:_-ednfFrO7SXL7fRnZ2dnUVZ_jKdnZ2d(a)posted.palinacquisition...
>
>> AFAIK, the hard (i.e. slow) part is loading the assembly. So if you have
>> to load the assembly just to inspect the attribute, that's probably not
>> significantly better than just iterating over the types in the assembly.
>
> Perhaps this would be where you'd want to use the ReflectionOnlyLoad[From]()
> method.

It's better, but it's still slow. And if you use that, you can't
actually execute the code in the assembly, which sort of negates the
point of loading the assembly to see if it contains a plug-in you want
to execute. :)

Pete
 | 
Pages: 1
Prev: delegate vs condition check
Next: Problem with TTable