Richard Brown
9/11/2004 3:21:00 AM
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" <ken.kolda@elliemae-nospamplease.com> wrote in message
news:%23XBPMlTlEHA.3608@TK2MSFTNGP09.phx.gbl...
> 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" <nospam@stopspamnow.org> wrote in message
> news:OqmcgmSlEHA.3476@tk2msftngp13.phx.gbl...
>> 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.
>>
>>
>>
>>
>
>