MBR IT/.NET 247 : Remoting Controls across AppDomains on microsoft.public.dotnet.framework.remoting

Remoting Controls across AppDomains

Messages

Related Types

This message was discovered on microsoft.public.dotnet.framework.remoting.

Richard Brown

I've read a myriad of posts, articles and other information sources on this,
but NONE seem to answer the question or provide a solution. Why am I going
insane? Here's the desired result and reasoning:

Desired Result and Reasoning:
Using a plugin architecture, allow loading of UserControl, or similar, based
user interface elements to build up the application functionality at
runtime. A user interface AppDomain is created and core extension
components can be loaded into the same AppDomain as the shell window. A
number of other interface components can be 'switched out', specifically
different mapping providers, and must be able to be unloaded and replaced
with the newly selected provider, thus, these few components should be
loaded into their own AppDomain.

The Problem:
This problem seems to be a wall hit by everyone I have run across. When
attempting to assign the parent property, or use the Controls.Add(...)
method on the shell, a SerializationException occurs because remoting cannot
access the 'parent' property. If I attempt to assign the Parent property on
the controls, I get the serialization error due to the
Form.ControlCollection not being serializable.

Minor Ranting:
Since I've been banging my head against the wall for almost a week now,
please forgive this minor rant --> WHO IN THE *ahem*'s bright idea was it
to make Controls and Forms inherit from MarshalByRefObject, *appear* to be
compatibile with this type or architecture, the go an put non-serializable
fields in the classes, that you apparently cant get around, or have remoting
try to access properties that CANT event be accessed through normal means.
Where exactly did the short-circuit happen, or what were they on? <-- end
of rant, thank you.

A Possible Idea:
There are two ideas that come up, I like the second more, but its still not
the solution I am looking for and my deadline is rapidly approaching (that
light at the end of the tunnel really IS the train!)

Idea 1: Inform the user that changes will take effect with the application
is restarted.
(No, dont like at all .. we aren't working in yesterday's technologies).

Idea 2: SInce the user interface is loaded into a seperate AppDomain, unload
the entire interface and reload it, similar to Idea 1, but we can cause it
to happen without user intervention.
(I like it better, but still seems pretty bad to me, and Im sure there are
going to be issues with it)

Foggy Idea 3: What about going back to the old-reliable HWND handles and
somehow linking the parent using a wrapped handle somehow? Havent really
gone indepth to see if this would work.

ANY help would be greatly appreciated!!!
Thanks in advance.

Richard Brown
"Insane Developer Undergoing Nervous Breakdown"

** Please also respond in email, be sure to check the address.

Reply to this message...

Ken Kolda

Let me make sure I undestand what you're trying to do. Are you trying to
create a UserControl in one AppDomain and set its parent to be a control in
a different AppDomain? If so, that certainly will not work. Think of
AppDomains as mini-applications. You couldn't create launch 2 EXEs and hope
to get a control in one process space to be the parent of a control in the
other. The fact that controls and forms are MarshalByRef is so they can be
remoted at all -- if they weren't you could never use one of these objects
as a remoting "server". It's not so you can create forms/controls with
elements from multiple AppDomains.

If I misunderstood, I apologize. Otherwise, I'd go with technique #2 below
and keep both the controls and the forms/controls that contain them in a
seperate AppDomain which you could unload as necessary.

Ken

"Richard Brown" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
> I've read a myriad of posts, articles and other information sources on
this,
> but NONE seem to answer the question or provide a solution. Why am I
going
[Original message clipped]

Reply to this message...

Richard Brown

Thank you, and I think you pretty much have the right idea of what I am
trying to accomplish.

But, if what you say is true, then I would definitely say that Microsoft has
a bug in their implementation.
As I mentioned, when I attempted to set the 'parent' property of the
UserControl in AppDomain2 to the Form instance
in AppDomain1, the synchronization error was that the ControlCollection in
the Form instance was not marked synchronizable.
This would imply to me, that Form instances could never be shared with a
remoting server, you would have to break out
relative data into a seperate MBR class and pass that -- however, then the
question comes back, why make controls and forms
inherit from MarshalByRef... I have a feeling I am missing some fundamental
concept here through my flawed logic, but
it *seems* not to be flawed to me.

I will probably go with option #2, but I really didn't want to have to
recreate the WHOLE UI when options are changed.
The idea was that in the UI, perhaps they have a form with a map displayed,
but the map can actually be configured to either use
ESRI MapObjects, or possibly MapPoint, or some other. Each of these has
their own controls, and I wanted to wrap an interface
around each one that the application could use, but in preferences or some
configuration, allow the user to switch them out.
If the user does this, with option #2, I essentially destroy the entire UI
and rebuild it, using some sort of momento design pattern
to remember windows, state, etc. What would be nice is just to unload the
AppDomain the vendor instance is in, recreate it with
the new vendor instance, update the interface wrapper to point to the new
app domain and leave the interface alone.

With that, anyone have any further ideas, or am I really reaching on this
one?
Also, could someone PLEASE help fix my logic error in the upper paragraph...
maybe a Microsoft Team Member blog who wants to explain to the minion
developers who just cant get it. ;-)

Thanks guys (and gals if your out there)

"Ken Kolda" <Click here to reveal e-mail address> wrote in message
news:%Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

	System.AppDomain
	System.MarshalByRefObject
	System.Runtime.Serialization.SerializationException
	System.Web.UI.ControlCollection
	System.Web.UI.UserControl
	System.Windows.Forms.Form
	System.Windows.Forms.UserControl

MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

	Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
	Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com