New Chapter on Plug Ins

[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.*Runtim e 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.Reflecti on.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Justin Rogers]

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.

--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Jeff Louie" <je********@yah oo.com> wrote in message
news:%2******** *******@TK2MSFT NGP11.phx.gbl.. .

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.Reflecti on.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jon Skeet [C# MVP]]

Jeff Louie <je********@yah oo.com> wrote:

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.IDrawa ble and DrawPlugIn.IDra wable. 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.WriteLi ne 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(IDrawab le).IsAssignabl eFrom(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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jeff Louie]

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.<
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jeff Louie]

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

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Justin Rogers]

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.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Jeff Louie" <je********@yah oo.com> wrote in message
news:Os******** *****@TK2MSFTNG P11.phx.gbl...

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.<
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!