AppDomain problem : Creating Controls in a separate AppDomain to display in Main AppDomain

[Bill Woodruff]

Visual Studio 2005, .NET FrameWork 2.0, C#, WinForms Application

Hi,

I've read the recent posts by and to 'Thunderbird' (and learned a lot,
thanks, from the usual masters Skeet and Paladino, and others) which involve
AppDomains in a remoting scenario, but I think the issue I am working with
.... while related ... is sufficiently different to warrant a new thread.

I'm also working on a plug-in architecture it's for a WinForms based
project.

At run-time I "discover" and load all the Plug-Ins that match a MainApp
Interface with no problem.

I find I can pass complex objects (like the TreeNode of a TreeView) to the
plug-ins' AppDomain, and modify certain properties and have the result show
up in the Main App's UI, no problem.

What I find I can't do ... I assume because WinForm objects like a TreeView
and the Nodes collection object of a TreeView are passed as proxies ... is
create new Nodes in the plug-in app domain and then pass them back to the
Main app and put them in the TreeView in the UI there.

Error trying to create a new TreeView Node in the Plug-In appDomain (yes,
Plug-Ins do contain references for WinForms) :

"SerializationE xception Crossed an AppDomain Boundary"

Type 'System.Windows .Forms.Control+ ControlCollecti on' in assembly
'System.Windows .Forms, Version=2.0.0.0 , Culture=neutral ,
PublicKeyToken= b77a5c561934e08 9' is not marked as serializable.

"Ideally" I'd like to pass the Plug-In a bounding rectangle definition, have
it create a collection of controls, and get those controls back to the Main
AppDomain and plug them into a Panel and then have the Plug-In, based on the
state of its controls, do the "right thing" to conjure up whatever objects
it wants to create and get those objects back to the Main App for
display/use in the main UI.

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.

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.

Appreciate any feedback. I have examined the various add-in/plug-in projects
of CodeProject, the usual books (Petzold, Sells, Liberty, Gunnerson).

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.

thanks !

Bill Woodruff
dotScience
Chiang Mai, Thailand

[Jon Skeet [C# MVP]]

Bill Woodruff <ms*********@do tscience.comwro te:

<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
MarshalByRefObj ect 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.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk