Bill Woodruff <ms*********@dotscience.comwrote:
<snip>
At this point I believe that is simply not possible ... although Jon Skeet's
comments in his reply to Thunderbird are still inviting me to reconsider and
re-think.
Well, it sounds like we're doing significantly different things. In my
case I was able to have a whole area of the main UI which the plugin
"owned", running that UI in a different thread.
What I do believe is most probable is that there is an optimum architecture
for a situation where :
1. you want to load plug-ins in a separate appDomain (in T'Bird's case one
appDomain per plug-in). so you can unload at will.
2. you want the plug-in to specify its run-time user interface to the Main
appDomain in some terse, easily parsable form.
3. you want the Main appDomain to present the Plug-In's controls/widgets in
the main UI, let the user alter their state at run-time.
4. you want the Plug-In (through direct action at run-time) to trigger some
process that results in modification of complex objects, or creation of new
ones in the Main appDomain.
Right, that sounds like a reasonable architecture, yes. Easier with WPF
of course, because of the business of specifying the user interface is
easy :)
It would help me greatly if I had a better sense of exactly what a "proxy"
is, and I appreciate any referrals to learning materials in that area.
Yes - AppDomains and marshalling is a fairly difficult topic to find
information about. Basically anything which derives from
MarshalByRefObject can be marshalled across an AppDomain boundary by
(automatically) creating a proxy which has a reference to the original
object. However, there are limitations as to what you can do, and I'm
afraid I'm far from an expert on that side of things :(
I basically try to do as little as possible across the app domain
boundary.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog:
http://www.msmvps.com/jon.skeet
World class .NET training in the UK:
http://iterativetraining.co.uk 
