New Chapter on Plug Ins

  • Thread starter Thread starter Jeff Louie
  • Start date Start date
J

Jeff Louie

I have added a chapter on dynamically loading classes (plug ins) using
Reflection. Code comments welcome from Jon Skeet or anyone else
interested in this.

http://www.geocities.com/jeff_louie/OOP/oop13.htm

In this chapter I am going to demonstrate the use of encapsulation and
polymorphism to allow the loading of a "plug in" class at
runtime. Runtime discovery is done using Reflection. The loading of a
third party plug in class at runtime is useful when you want to add new
functionality to an existing program. Since the application does not
know
the name of the plug in class at compile time, the application must
"discover" the new class at runtime. This is done with
System.Reflection.

Regards,
Jeff
 
When you are done with the basic framework, I would be willing to go over your
code and discuss a security architecture for loading *third-party* or untrusted
plug-ins
into the system.

This might even be an additional chapter, but I've done numerous amounts of work
in
regards to interfacing programming against an unknown type that can *ask* for
various
resources at run-tme and providing user feedback to allow said plug-in those
permissions.

Because everything is handled at run-time, as long as the plug-in doesn't make
declarative
(attribute based) security requests the assembly will load and execute fine.
Once they request
heightened permissions and are either approved or disapproved by the user, they
can then
continue to run under lessened security or choose to not run. Very interesting
stuff.

Go ahead and contact me via email if you are interested in this type of
collaboration.
 
Jeff Louie said:
I have added a chapter on dynamically loading classes (plug ins) using
Reflection. Code comments welcome from Jon Skeet or anyone else
interested in this.

<snip>

I take issue with this:
In this hands on tutorial, you will create three projects: DrawDemo,
MyInterface and DrawPlugIn. Although you can define an interface IDrawable
in the main project DrawDemo and in the plug in project DrawPlugIn,
the two interfaces will have different fully qualified names
DrawDemo.IDrawable and DrawPlugIn.IDrawable. To avoid name collisions,
you should create a separate utility project MyInterface and define the
IDrawable interface in this separate assembly

The point of putting it in a separate interface *isn't* to avoid naming
problems - you could easily have the same interface name in both
assemblies, but they would still be different types. The full name
including namespace (which I *think* is what you're getting at here)
could be the same, but the full name including *assembly* name would be
different.

(I'd also change System.Console.WriteLine to just Console.WriteLine to
match the rest of your code, but there we go.)

I also don't like using just
if (t.GetInterface ("IDrawable")!=null)

Instead, use

if (typeof(IDrawable).IsAssignableFrom(t))

which is safer. You could still get casting exceptions from your code
if a type implements a *different* interface called IDrawable.

Other than that, very nice.
 
Justin.... Good point. I should, and will, mention security in this
chapter.
Security is probably beyond the "intent" of the tutorial. Would you be
willing to modify or extend the code for security and then I can add a
link to your site?

Regards,
Jeff
When you are done with the basic framework, I would be willing to go
over your code and discuss a security architecture for loading *third-
party* or untrusted plug-ins into the system.<
 
Hi Jon... Thanks again for your useful comments. I obviously did not
fully
understand that the name resolution problem you discussed. I just went
ahead and placed the interface in a separate assembly as per your
article.
I will implement all of your suggestions.

Regards,
Jeff
 
Yes, I'll start throwing something together on plug-in security. What is
possible
and what is not. It might be done in a couple of articles, but I'll toss them
your way.
 
Back
Top