Adding a control from a different AppDomain... how?

Adding a control from a different AppDomain... how?

am 14.01.2008 17:33:31 von ThunderMusic

Hi,
I currently have an application that must load plugins. It's impossible to
unload an assembly inside a single AppDomain, so I must create a different
AppDomain for each plugin I load so I can uload it when I don't need it
anymore. In the design document I received, I have to create the following :
"Load the assembly, get the configuration user control, display the user
control... When the user control is not needed anymore, unload the
assembly."... I can load the assembly (in a different appdomain), I can get
the user control, I can unload the assembly (by unloading the appdomain),
but I can't display the user control because I receive an exception (which I
don't really understand) : "Remoting cannot find field 'parent' on type
'System.Windows.Forms.Control'."... How can it not find the field 'parent'?
Is there a way to make it work? I can't believe MS didn't think about this
possibility which is used in about all "plugin based" application, so there
must be something I'm missing.

Thanks

ThunderMusic

Re: Adding a control from a different AppDomain... how?

am 14.01.2008 17:46:24 von mvp

The solution that you have right now is to use the System.AddIn
namespace, and use a WPF control from another app domain (this scenario is
supported). The WPF control would then have Windows Forms controls embedded
in it (through Windows Forms <-> WPF interop) and you would embed that
control on your form. Here is the post from the CLR Add-In Team Blog which
explains the process:

http://blogs.msdn.com/clraddins/archive/2008/01/03/support-f or-windows-forms-in-hosts-and-add-ins.aspx


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com

"ThunderMusic" wrote in message
news:%236P7ttsVIHA.2368@TK2MSFTNGP05.phx.gbl...
> Hi,
> I currently have an application that must load plugins. It's impossible to
> unload an assembly inside a single AppDomain, so I must create a different
> AppDomain for each plugin I load so I can uload it when I don't need it
> anymore. In the design document I received, I have to create the following
> : "Load the assembly, get the configuration user control, display the user
> control... When the user control is not needed anymore, unload the
> assembly."... I can load the assembly (in a different appdomain), I can
> get the user control, I can unload the assembly (by unloading the
> appdomain), but I can't display the user control because I receive an
> exception (which I don't really understand) : "Remoting cannot find field
> 'parent' on type 'System.Windows.Forms.Control'."... How can it not find
> the field 'parent'? Is there a way to make it work? I can't believe MS
> didn't think about this possibility which is used in about all "plugin
> based" application, so there must be something I'm missing.
>
> Thanks
>
> ThunderMusic
>

Re: Adding a control from a different AppDomain... how?

am 14.01.2008 17:59:18 von ThunderMusic

hi, thanks for your answer... but it would require framework 3.5 and we
have to use 2.0 right now because the application has been created some time
ago and we only have VS 2005...

Thanks

ThunderMusic

"Nicholas Paldino [.NET/C# MVP]" wrote in
message news:%23wfuZxsVIHA.5132@TK2MSFTNGP02.phx.gbl...
> The solution that you have right now is to use the System.AddIn
> namespace, and use a WPF control from another app domain (this scenario is
> supported). The WPF control would then have Windows Forms controls
> embedded in it (through Windows Forms <-> WPF interop) and you would embed
> that control on your form. Here is the post from the CLR Add-In Team Blog
> which explains the process:
>
> http://blogs.msdn.com/clraddins/archive/2008/01/03/support-f or-windows-forms-in-hosts-and-add-ins.aspx
>
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - mvp@spam.guard.caspershouse.com
>
> "ThunderMusic" wrote in message
> news:%236P7ttsVIHA.2368@TK2MSFTNGP05.phx.gbl...
>> Hi,
>> I currently have an application that must load plugins. It's impossible
>> to unload an assembly inside a single AppDomain, so I must create a
>> different AppDomain for each plugin I load so I can uload it when I don't
>> need it anymore. In the design document I received, I have to create the
>> following : "Load the assembly, get the configuration user control,
>> display the user control... When the user control is not needed anymore,
>> unload the assembly."... I can load the assembly (in a different
>> appdomain), I can get the user control, I can unload the assembly (by
>> unloading the appdomain), but I can't display the user control because I
>> receive an exception (which I don't really understand) : "Remoting cannot
>> find field 'parent' on type 'System.Windows.Forms.Control'."... How can
>> it not find the field 'parent'? Is there a way to make it work? I can't
>> believe MS didn't think about this possibility which is used in about all
>> "plugin based" application, so there must be something I'm missing.
>>
>> Thanks
>>
>> ThunderMusic
>>
>
>

Re: Adding a control from a different AppDomain... how?

am 14.01.2008 18:10:05 von ThunderMusic

Hi, thanks for your answer....

you say : "Never create a control on a thread or in an appdomain other than
the one which it will essentially be running in."...
How can I create a control directly from my application's AppDomain if I
want to load it from the assembly and unload (or dispose) the assembly
afterward? To do this, I must create it in a different AppDomain (if I
understand it all right). Actually, all we need to do is done and working,
except this point... If we load the assembly from the main AppDomain,
everything works great, but we need to unload the assemblies so we don't
take like 1gb of memory... ;) the plugins can be pretty big (like 10-12Mb
each) and there can be many (up to int.Max) so we don't want our users to
have to restart the application because they loaded up too many plugins in
the same session just because we can't unload them...

Take for instance, a product that is well known (not MS tought), Cakewalk
Sonar, or Digidesign Protools (audio products)... They use VST plugins (and
many others types)... each plugin has it's own UI for configuration...
That's exactly what we want to do... Can you imagine such products if they
didn't unload the plugins they used in the session? the memory would
increase and increase so nothing else can be done... it would be awful...

Well anyway... I use different AppDomain to load the assemblies, get the
Usercontrols from these appdomains and keep the appdomain alive during all
my use of the created usercontrol, and unload the appdomain when the
usercontrol is not needed anymore and the process is done... If it is in
anyway possible to unload an assembly from the main appdomain or to use a
user control from a second appdomain, I need to know how... ;)

Thanks a lot

ThunderMusic




"Jon Skeet [C# MVP]" wrote in message
news:33a2d533-d403-4ae3-adf7-954a09f5180a@k2g2000hse.googleg roups.com...
> On Jan 14, 4:33 pm, "ThunderMusic"
> wrote:
>> I currently have an application that must load plugins. It's impossible
>> to
>> unload an assembly inside a single AppDomain, so I must create a
>> different
>> AppDomain for each plugin I load so I can uload it when I don't need it
>> anymore. In the design document I received, I have to create the
>> following :
>> "Load the assembly, get the configuration user control, display the user
>> control... When the user control is not needed anymore, unload the
>> assembly."... I can load the assembly (in a different appdomain), I can
>> get
>> the user control, I can unload the assembly (by unloading the appdomain),
>> but I can't display the user control because I receive an exception
>> (which I
>> don't really understand) : "Remoting cannot find field 'parent' on type
>> 'System.Windows.Forms.Control'."... How can it not find the field
>> 'parent'?
>> Is there a way to make it work? I can't believe MS didn't think about
>> this
>> possibility which is used in about all "plugin based" application, so
>> there
>> must be something I'm missing.
>
> My experience is that this will work, with a *lot* of careful work, so
> long as you make the plugins each have their own message pump. They
> need to be in their own windows which are then reparented (Windows
> SetParent call). Be very careful when threading calls between the
> plugin and the host. Never create a control on a thread or in an
> appdomain other than the one which it will essentially be running in.
>
> You'll find a lot of posts saying all of this can't be done. It can,
> but you need to be careful - and you really do need a message pump in
> each AppDomain.
>
> Jon

Re: Adding a control from a different AppDomain... how?

am 14.01.2008 18:28:00 von londoncalling

Hi ThunderMusic.. No real answers but maybe some things to think about.. Does
the UI and the actual bones of the processing (I'm assuming audio FX) have to
be in the same assembly? If not the UI can be part of the same App domain and
just create 'unloadable' appdomains to host the processors as required.. Also
are the assemblies so big because they contain lots of embedded resources? if
so could they be moved to disk and forget unloading the assembly? just a
thought.. jd

"ThunderMusic" wrote:

> Hi, thanks for your answer....
>
> you say : "Never create a control on a thread or in an appdomain other than
> the one which it will essentially be running in."...
> How can I create a control directly from my application's AppDomain if I
> want to load it from the assembly and unload (or dispose) the assembly
> afterward? To do this, I must create it in a different AppDomain (if I
> understand it all right). Actually, all we need to do is done and working,
> except this point... If we load the assembly from the main AppDomain,
> everything works great, but we need to unload the assemblies so we don't
> take like 1gb of memory... ;) the plugins can be pretty big (like 10-12Mb
> each) and there can be many (up to int.Max) so we don't want our users to
> have to restart the application because they loaded up too many plugins in
> the same session just because we can't unload them...
>
> Take for instance, a product that is well known (not MS tought), Cakewalk
> Sonar, or Digidesign Protools (audio products)... They use VST plugins (and
> many others types)... each plugin has it's own UI for configuration...
> That's exactly what we want to do... Can you imagine such products if they
> didn't unload the plugins they used in the session? the memory would
> increase and increase so nothing else can be done... it would be awful...
>
> Well anyway... I use different AppDomain to load the assemblies, get the
> Usercontrols from these appdomains and keep the appdomain alive during all
> my use of the created usercontrol, and unload the appdomain when the
> usercontrol is not needed anymore and the process is done... If it is in
> anyway possible to unload an assembly from the main appdomain or to use a
> user control from a second appdomain, I need to know how... ;)
>
> Thanks a lot
>
> ThunderMusic
>
>
>
>
> "Jon Skeet [C# MVP]" wrote in message
> news:33a2d533-d403-4ae3-adf7-954a09f5180a@k2g2000hse.googleg roups.com...
> > On Jan 14, 4:33 pm, "ThunderMusic"
> > wrote:
> >> I currently have an application that must load plugins. It's impossible
> >> to
> >> unload an assembly inside a single AppDomain, so I must create a
> >> different
> >> AppDomain for each plugin I load so I can uload it when I don't need it
> >> anymore. In the design document I received, I have to create the
> >> following :
> >> "Load the assembly, get the configuration user control, display the user
> >> control... When the user control is not needed anymore, unload the
> >> assembly."... I can load the assembly (in a different appdomain), I can
> >> get
> >> the user control, I can unload the assembly (by unloading the appdomain),
> >> but I can't display the user control because I receive an exception
> >> (which I
> >> don't really understand) : "Remoting cannot find field 'parent' on type
> >> 'System.Windows.Forms.Control'."... How can it not find the field
> >> 'parent'?
> >> Is there a way to make it work? I can't believe MS didn't think about
> >> this
> >> possibility which is used in about all "plugin based" application, so
> >> there
> >> must be something I'm missing.
> >
> > My experience is that this will work, with a *lot* of careful work, so
> > long as you make the plugins each have their own message pump. They
> > need to be in their own windows which are then reparented (Windows
> > SetParent call). Be very careful when threading calls between the
> > plugin and the host. Never create a control on a thread or in an
> > appdomain other than the one which it will essentially be running in.
> >
> > You'll find a lot of posts saying all of this can't be done. It can,
> > but you need to be careful - and you really do need a message pump in
> > each AppDomain.
> >
> > Jon
>
>
>

Re: Adding a control from a different AppDomain... how?

am 14.01.2008 18:48:46 von skeet

ThunderMusic wrote:
> Hi, thanks for your answer....
>
> you say : "Never create a control on a thread or in an appdomain other than
> the one which it will essentially be running in."...
> How can I create a control directly from my application's AppDomain if I
> want to load it from the assembly and unload (or dispose) the assembly
> afterward?

You need to load one of your assemblies into the new AppDomain, and get
that to create the control.

> To do this, I must create it in a different AppDomain (if I
> understand it all right). Actually, all we need to do is done and working,
> except this point... If we load the assembly from the main AppDomain,
> everything works great, but we need to unload the assemblies so we don't
> take like 1gb of memory... ;) the plugins can be pretty big (like 10-12Mb
> each) and there can be many (up to int.Max) so we don't want our users to
> have to restart the application because they loaded up too many plugins in
> the same session just because we can't unload them...

Indeed. That's one of the reasons we do it too.

> Take for instance, a product that is well known (not MS tought), Cakewalk
> Sonar, or Digidesign Protools (audio products)... They use VST plugins (and
> many others types)... each plugin has it's own UI for configuration...
> That's exactly what we want to do... Can you imagine such products if they
> didn't unload the plugins they used in the session? the memory would
> increase and increase so nothing else can be done... it would be awful...
>
> Well anyway... I use different AppDomain to load the assemblies, get the
> Usercontrols from these appdomains and keep the appdomain alive during all
> my use of the created usercontrol, and unload the appdomain when the
> usercontrol is not needed anymore and the process is done... If it is in
> anyway possible to unload an assembly from the main appdomain or to use a
> user control from a second appdomain, I need to know how... ;)

No, you can't unload a single assembly from an AppDomain, you have to
unload the whole AppDomain. The important bit is to get some of your
own code (just enough) running in the new AppDomain, so that you can
control it from your "main" AppDomain but still create appropriate
objects (most importantly UI controls) inside the new AppDomain, in the
right thread.

--
Jon Skeet -
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Re: Adding a control from a different AppDomain... how?

am 14.01.2008 18:50:00 von londoncalling

Maybe more helpful.. check out the System.AddIn namespace/subspaces.. HTH jd

"london calling" wrote:

> Hi ThunderMusic.. No real answers but maybe some things to think about.. Does
> the UI and the actual bones of the processing (I'm assuming audio FX) have to
> be in the same assembly? If not the UI can be part of the same App domain and
> just create 'unloadable' appdomains to host the processors as required.. Also
> are the assemblies so big because they contain lots of embedded resources? if
> so could they be moved to disk and forget unloading the assembly? just a
> thought.. jd
>
> "ThunderMusic" wrote:
>
> > Hi, thanks for your answer....
> >
> > you say : "Never create a control on a thread or in an appdomain other than
> > the one which it will essentially be running in."...
> > How can I create a control directly from my application's AppDomain if I
> > want to load it from the assembly and unload (or dispose) the assembly
> > afterward? To do this, I must create it in a different AppDomain (if I
> > understand it all right). Actually, all we need to do is done and working,
> > except this point... If we load the assembly from the main AppDomain,
> > everything works great, but we need to unload the assemblies so we don't
> > take like 1gb of memory... ;) the plugins can be pretty big (like 10-12Mb
> > each) and there can be many (up to int.Max) so we don't want our users to
> > have to restart the application because they loaded up too many plugins in
> > the same session just because we can't unload them...
> >
> > Take for instance, a product that is well known (not MS tought), Cakewalk
> > Sonar, or Digidesign Protools (audio products)... They use VST plugins (and
> > many others types)... each plugin has it's own UI for configuration...
> > That's exactly what we want to do... Can you imagine such products if they
> > didn't unload the plugins they used in the session? the memory would
> > increase and increase so nothing else can be done... it would be awful...
> >
> > Well anyway... I use different AppDomain to load the assemblies, get the
> > Usercontrols from these appdomains and keep the appdomain alive during all
> > my use of the created usercontrol, and unload the appdomain when the
> > usercontrol is not needed anymore and the process is done... If it is in
> > anyway possible to unload an assembly from the main appdomain or to use a
> > user control from a second appdomain, I need to know how... ;)
> >
> > Thanks a lot
> >
> > ThunderMusic
> >
> >
> >
> >
> > "Jon Skeet [C# MVP]" wrote in message
> > news:33a2d533-d403-4ae3-adf7-954a09f5180a@k2g2000hse.googleg roups.com...
> > > On Jan 14, 4:33 pm, "ThunderMusic"
> > > wrote:
> > >> I currently have an application that must load plugins. It's impossible
> > >> to
> > >> unload an assembly inside a single AppDomain, so I must create a
> > >> different
> > >> AppDomain for each plugin I load so I can uload it when I don't need it
> > >> anymore. In the design document I received, I have to create the
> > >> following :
> > >> "Load the assembly, get the configuration user control, display the user
> > >> control... When the user control is not needed anymore, unload the
> > >> assembly."... I can load the assembly (in a different appdomain), I can
> > >> get
> > >> the user control, I can unload the assembly (by unloading the appdomain),
> > >> but I can't display the user control because I receive an exception
> > >> (which I
> > >> don't really understand) : "Remoting cannot find field 'parent' on type
> > >> 'System.Windows.Forms.Control'."... How can it not find the field
> > >> 'parent'?
> > >> Is there a way to make it work? I can't believe MS didn't think about
> > >> this
> > >> possibility which is used in about all "plugin based" application, so
> > >> there
> > >> must be something I'm missing.
> > >
> > > My experience is that this will work, with a *lot* of careful work, so
> > > long as you make the plugins each have their own message pump. They
> > > need to be in their own windows which are then reparented (Windows
> > > SetParent call). Be very careful when threading calls between the
> > > plugin and the host. Never create a control on a thread or in an
> > > appdomain other than the one which it will essentially be running in.
> > >
> > > You'll find a lot of posts saying all of this can't be done. It can,
> > > but you need to be careful - and you really do need a message pump in
> > > each AppDomain.
> > >
> > > Jon
> >
> >
> >

Re: Adding a control from a different AppDomain... how?

am 14.01.2008 18:55:02 von londoncalling

sorry.. it's a 3.5 namespace..

"london calling" wrote:

> Maybe more helpful.. check out the System.AddIn namespace/subspaces.. HTH jd
>
> "london calling" wrote:
>
> > Hi ThunderMusic.. No real answers but maybe some things to think about.. Does
> > the UI and the actual bones of the processing (I'm assuming audio FX) have to
> > be in the same assembly? If not the UI can be part of the same App domain and
> > just create 'unloadable' appdomains to host the processors as required.. Also
> > are the assemblies so big because they contain lots of embedded resources? if
> > so could they be moved to disk and forget unloading the assembly? just a
> > thought.. jd
> >
> > "ThunderMusic" wrote:
> >
> > > Hi, thanks for your answer....
> > >
> > > you say : "Never create a control on a thread or in an appdomain other than
> > > the one which it will essentially be running in."...
> > > How can I create a control directly from my application's AppDomain if I
> > > want to load it from the assembly and unload (or dispose) the assembly
> > > afterward? To do this, I must create it in a different AppDomain (if I
> > > understand it all right). Actually, all we need to do is done and working,
> > > except this point... If we load the assembly from the main AppDomain,
> > > everything works great, but we need to unload the assemblies so we don't
> > > take like 1gb of memory... ;) the plugins can be pretty big (like 10-12Mb
> > > each) and there can be many (up to int.Max) so we don't want our users to
> > > have to restart the application because they loaded up too many plugins in
> > > the same session just because we can't unload them...
> > >
> > > Take for instance, a product that is well known (not MS tought), Cakewalk
> > > Sonar, or Digidesign Protools (audio products)... They use VST plugins (and
> > > many others types)... each plugin has it's own UI for configuration...
> > > That's exactly what we want to do... Can you imagine such products if they
> > > didn't unload the plugins they used in the session? the memory would
> > > increase and increase so nothing else can be done... it would be awful...
> > >
> > > Well anyway... I use different AppDomain to load the assemblies, get the
> > > Usercontrols from these appdomains and keep the appdomain alive during all
> > > my use of the created usercontrol, and unload the appdomain when the
> > > usercontrol is not needed anymore and the process is done... If it is in
> > > anyway possible to unload an assembly from the main appdomain or to use a
> > > user control from a second appdomain, I need to know how... ;)
> > >
> > > Thanks a lot
> > >
> > > ThunderMusic
> > >
> > >
> > >
> > >
> > > "Jon Skeet [C# MVP]" wrote in message
> > > news:33a2d533-d403-4ae3-adf7-954a09f5180a@k2g2000hse.googleg roups.com...
> > > > On Jan 14, 4:33 pm, "ThunderMusic"
> > > > wrote:
> > > >> I currently have an application that must load plugins. It's impossible
> > > >> to
> > > >> unload an assembly inside a single AppDomain, so I must create a
> > > >> different
> > > >> AppDomain for each plugin I load so I can uload it when I don't need it
> > > >> anymore. In the design document I received, I have to create the
> > > >> following :
> > > >> "Load the assembly, get the configuration user control, display the user
> > > >> control... When the user control is not needed anymore, unload the
> > > >> assembly."... I can load the assembly (in a different appdomain), I can
> > > >> get
> > > >> the user control, I can unload the assembly (by unloading the appdomain),
> > > >> but I can't display the user control because I receive an exception
> > > >> (which I
> > > >> don't really understand) : "Remoting cannot find field 'parent' on type
> > > >> 'System.Windows.Forms.Control'."... How can it not find the field
> > > >> 'parent'?
> > > >> Is there a way to make it work? I can't believe MS didn't think about
> > > >> this
> > > >> possibility which is used in about all "plugin based" application, so
> > > >> there
> > > >> must be something I'm missing.
> > > >
> > > > My experience is that this will work, with a *lot* of careful work, so
> > > > long as you make the plugins each have their own message pump. They
> > > > need to be in their own windows which are then reparented (Windows
> > > > SetParent call). Be very careful when threading calls between the
> > > > plugin and the host. Never create a control on a thread or in an
> > > > appdomain other than the one which it will essentially be running in.
> > > >
> > > > You'll find a lot of posts saying all of this can't be done. It can,
> > > > but you need to be careful - and you really do need a message pump in
> > > > each AppDomain.
> > > >
> > > > Jon
> > >
> > >
> > >

Re: Adding a control from a different AppDomain... how?

am 14.01.2008 19:08:36 von ThunderMusic

Hi,
It actually not audio FX... The current architecture is that we have a
Windows service running which is loading the assemblies to run some
monitoring modules. There's also a "client" application which connects to
the Windows service and asks for a list of the loaded modules and displays
them in a treeview (for design purposes). When the user clicks on the node
of a module, it can see it's configuration control appear in the panel
beside the treeview. Well, that's actually what it should do... Passing a
control via remoting alone doesn't work at all... Actually, the control
goes though, but I can't add it to the panel saying it can't call a static
method remotly... anyways... so we decided to send the library itself (in a
byte[]) via remoting and the client app loads it dynamicly to get the
control and then binds it to the proxy to the remote class in the service to
the module it must be bound to. Right now, everything works fine if we load
the assembly locally in the main AppDomain, but it seems that if remoting is
involved at all, nothing can be done for user controls even if it's
"transparent"...

So we'll try to find something to solve our problem...

Thanks

ThunderMusic

"london calling" wrote in message
news:49398ED9-CDF0-420F-B669-1C7F581C1F7F@microsoft.com...
> Hi ThunderMusic.. No real answers but maybe some things to think about..
> Does
> the UI and the actual bones of the processing (I'm assuming audio FX) have
> to
> be in the same assembly? If not the UI can be part of the same App domain
> and
> just create 'unloadable' appdomains to host the processors as required..
> Also
> are the assemblies so big because they contain lots of embedded resources?
> if
> so could they be moved to disk and forget unloading the assembly? just a
> thought.. jd
>
> "ThunderMusic" wrote:
>
>> Hi, thanks for your answer....
>>
>> you say : "Never create a control on a thread or in an appdomain other
>> than
>> the one which it will essentially be running in."...
>> How can I create a control directly from my application's AppDomain if I
>> want to load it from the assembly and unload (or dispose) the assembly
>> afterward? To do this, I must create it in a different AppDomain (if I
>> understand it all right). Actually, all we need to do is done and
>> working,
>> except this point... If we load the assembly from the main AppDomain,
>> everything works great, but we need to unload the assemblies so we don't
>> take like 1gb of memory... ;) the plugins can be pretty big (like
>> 10-12Mb
>> each) and there can be many (up to int.Max) so we don't want our users to
>> have to restart the application because they loaded up too many plugins
>> in
>> the same session just because we can't unload them...
>>
>> Take for instance, a product that is well known (not MS tought), Cakewalk
>> Sonar, or Digidesign Protools (audio products)... They use VST plugins
>> (and
>> many others types)... each plugin has it's own UI for configuration...
>> That's exactly what we want to do... Can you imagine such products if
>> they
>> didn't unload the plugins they used in the session? the memory would
>> increase and increase so nothing else can be done... it would be
>> awful...
>>
>> Well anyway... I use different AppDomain to load the assemblies, get the
>> Usercontrols from these appdomains and keep the appdomain alive during
>> all
>> my use of the created usercontrol, and unload the appdomain when the
>> usercontrol is not needed anymore and the process is done... If it is in
>> anyway possible to unload an assembly from the main appdomain or to use a
>> user control from a second appdomain, I need to know how... ;)
>>
>> Thanks a lot
>>
>> ThunderMusic
>>
>>
>>
>>
>> "Jon Skeet [C# MVP]" wrote in message
>> news:33a2d533-d403-4ae3-adf7-954a09f5180a@k2g2000hse.googleg roups.com...
>> > On Jan 14, 4:33 pm, "ThunderMusic"
>> > wrote:
>> >> I currently have an application that must load plugins. It's
>> >> impossible
>> >> to
>> >> unload an assembly inside a single AppDomain, so I must create a
>> >> different
>> >> AppDomain for each plugin I load so I can uload it when I don't need
>> >> it
>> >> anymore. In the design document I received, I have to create the
>> >> following :
>> >> "Load the assembly, get the configuration user control, display the
>> >> user
>> >> control... When the user control is not needed anymore, unload the
>> >> assembly."... I can load the assembly (in a different appdomain), I
>> >> can
>> >> get
>> >> the user control, I can unload the assembly (by unloading the
>> >> appdomain),
>> >> but I can't display the user control because I receive an exception
>> >> (which I
>> >> don't really understand) : "Remoting cannot find field 'parent' on
>> >> type
>> >> 'System.Windows.Forms.Control'."... How can it not find the field
>> >> 'parent'?
>> >> Is there a way to make it work? I can't believe MS didn't think about
>> >> this
>> >> possibility which is used in about all "plugin based" application, so
>> >> there
>> >> must be something I'm missing.
>> >
>> > My experience is that this will work, with a *lot* of careful work, so
>> > long as you make the plugins each have their own message pump. They
>> > need to be in their own windows which are then reparented (Windows
>> > SetParent call). Be very careful when threading calls between the
>> > plugin and the host. Never create a control on a thread or in an
>> > appdomain other than the one which it will essentially be running in.
>> >
>> > You'll find a lot of posts saying all of this can't be done. It can,
>> > but you need to be careful - and you really do need a message pump in
>> > each AppDomain.
>> >
>> > Jon
>>
>>
>>

Re: Adding a control from a different AppDomain... how?

am 14.01.2008 19:09:25 von ThunderMusic

thanks a lot for your help... ;)

"Jon Skeet [C# MVP]" wrote in message
news:MPG.21f5b0dc840c57c67ac@msnews.microsoft.com...
> ThunderMusic wrote:
>> Hi, thanks for your answer....
>>
>> you say : "Never create a control on a thread or in an appdomain other
>> than
>> the one which it will essentially be running in."...
>> How can I create a control directly from my application's AppDomain if I
>> want to load it from the assembly and unload (or dispose) the assembly
>> afterward?
>
> You need to load one of your assemblies into the new AppDomain, and get
> that to create the control.
>
>> To do this, I must create it in a different AppDomain (if I
>> understand it all right). Actually, all we need to do is done and
>> working,
>> except this point... If we load the assembly from the main AppDomain,
>> everything works great, but we need to unload the assemblies so we don't
>> take like 1gb of memory... ;) the plugins can be pretty big (like
>> 10-12Mb
>> each) and there can be many (up to int.Max) so we don't want our users to
>> have to restart the application because they loaded up too many plugins
>> in
>> the same session just because we can't unload them...
>
> Indeed. That's one of the reasons we do it too.
>
>> Take for instance, a product that is well known (not MS tought), Cakewalk
>> Sonar, or Digidesign Protools (audio products)... They use VST plugins
>> (and
>> many others types)... each plugin has it's own UI for configuration...
>> That's exactly what we want to do... Can you imagine such products if
>> they
>> didn't unload the plugins they used in the session? the memory would
>> increase and increase so nothing else can be done... it would be
>> awful...
>>
>> Well anyway... I use different AppDomain to load the assemblies, get the
>> Usercontrols from these appdomains and keep the appdomain alive during
>> all
>> my use of the created usercontrol, and unload the appdomain when the
>> usercontrol is not needed anymore and the process is done... If it is in
>> anyway possible to unload an assembly from the main appdomain or to use a
>> user control from a second appdomain, I need to know how... ;)
>
> No, you can't unload a single assembly from an AppDomain, you have to
> unload the whole AppDomain. The important bit is to get some of your
> own code (just enough) running in the new AppDomain, so that you can
> control it from your "main" AppDomain but still create appropriate
> objects (most importantly UI controls) inside the new AppDomain, in the
> right thread.
>
> --
> Jon Skeet -
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> World class .NET training in the UK: http://iterativetraining.co.uk

Re: Adding a control from a different AppDomain... how?

am 15.01.2008 22:48:51 von ThunderMusic

not, as they affirm, the
uncertainty of all our knowledge. For the knowledge of first principles, as
space, time, motion, number, is as sure as any of those which we get from
reasoning. And reason must trust these intuitions of the heart, and must
base them on every argument. (We have intuitive knowledge of the
tri-dimensional nature of space and of the infinity of number, and reason
then shows that there are no two square numbers one of which is double of
the other. Principles are intuited, propositions are inferred, all with
certainty, though in different ways.) And it is as useless and absurd for
reason to demand from the heart proofs of her first principles, before
admitting them, as it would be for the heart to demand from reason an
intuition of all demonstrated propositions before accepting them.

This inability ought, then, to serve only to humble reason, which would
judge all, but not to impugn our certainty, as if only reason were capable
of instructing us. Would to God, on the contrary, that we had never need of
it, and that we knew everything by instinct and intuition! But nature has
refused us this boon. On the contrary, she has given us but very little
knowledge of this kind; and all the rest can be acquired only by reasoning.

Therefore, those to whom God has imparted religion by intuition are very
fortunate and justly convinced. But to those who do not have it, we can give
it only by reasoning, waiting for God to give them spiritual insight,
without which faith is only human and useless for salvation.

283. Order.--Against the objection that Scripture has no order.

The heart has its own order; the intellect has its own, which is by
principle and demonstration. T

Re: Adding a control from a different AppDomain... how?

am 15.01.2008 22:52:09 von ThunderMusic

We know that we do not dream, and,
however impossible it is for us to prove it by reason, this inability
demonstrates only the weakness of our reason, but not, as they affirm, the
uncertainty of all our knowledge. For the knowledge of first principles, as
space, time, motion, number, is as sure as any of those which we get from
reasoning. And reason must trust these intuitions of the heart, and must
base them on every argument. (We have intuitive knowledge of the
tri-dimensional nature of space and of the infinity of number, and reason
then shows that there are no two square numbers one of which is double of
the other. Principles are intuited, propositions are inferred, all with
certainty, though in different ways.) And it is as useless and absurd for
reason to demand from the heart proofs of her first principles, before
admitting them, as it would be for the heart to demand from reason an
intuition of all demonstrated propositions before accepting them.

This inability ought, then, to serve only to humble reason, which would
judge all, but not to impugn our certainty, as if only reason were capable
of instructing us. Would to God, on the contrary, that we had never need o

Re: Adding a control from a different AppDomain... how?

am 15.01.2008 23:03:45 von skeet

kinds of people one can call reasonable; those who serve God
with all their heart because they know Him, and those who seek Him with all
their heart because they do not know Him.

But as for those who live without knowing Him and without seeking Him, they
judge themselves so little worthy of their own care, that they are not
worthy of the care of others; and it needs all the charity of the religion
which they despise, not to despise them even to the point of leaving them to
their folly. But because this religion obliges us always to regard them, so
long as they are in this life, as capable of the grace which can enlighten
them, and to believe that they may, in a little time, be more replenished
with faith than we are, and that, on the other hand, we may fall into the
blindness wherein they are, we must do for them what we would they should do
for us if we were in their place, and call upon them to have pity upon
themselves, and to take at least some steps in the endeavour to find light.
Let them give to reading this some of the hours which they otherwise employ
so uselessly; whatever aversion they may bring to the task, they will
perhaps gain something, and at least will not lose much. But as for those
who bring to the task perfect sincerity and a real desire to meet with
truth, those I hope will be satisfied and convinced of the proofs of a
religion so divine, which I have here collected, and in which I have
followed somewhat after this order...

195. Before entering into the proofs of the Christian religion, I find it
necessary to point out the sinfulness of those men who live in indifference
to the search for truth in a matter w

Re: Adding a control from a different AppDomain... how?

am 15.01.2008 23:40:35 von ThunderMusic

to fast and be
self-satisfied therewith. The Pharisee and the Publican.

What use will memory be to me, if it can alike hurt and help me, and all
depends upon the blessing of God, who gives only to things done for Him,
according to His rules and in His ways, the manner being thus as important
as the thing and perhaps more; since God can bring forth good out of evil,
and without God we bring forth evil out of good?

500. The meaning of the words, good and evil.

501. First step: to be blamed for doing evil, and praised for doing good.

Second step: to be neither praised nor blamed.

502. Abraham took nothing for himself, but only for his servants. So the
righteous man takes for himself nothing of the world, nor of the applause of
the world, but only for his passions, which he uses as their master, saying
to the one, "Go," and to another, "Come." Sub te erit appetitus tuus.77 The
passions thus subdued are virtues. Even God attributes to Himself avarice,
jealousy, anger; and these are virtues as well as kindness, pity, constancy,
which are also passions. We must employ them as slaves, and, leaving to them
their food, prevent the soul from taking any of it, For, when the passions
become masters,

Re: Adding a control from a different AppDomain... how?

am 15.01.2008 23:56:02 von londoncalling

and particularly that it much failed of duly representing her
humility, and that admirable lowliness of heart, that all times appeared
in her. But there are, blessed be God! many living instances, of much
the like nature, and in some things no less extraordinary.

But I now proceed to the other instance, that of the little child before
mentioned. Her name is Phebe Bartlet, [She was living in March, 1789,
and maintained the character of a true convert.] daughter of William
Bartlet. I shall give the account as I took it from the mouth of her
parents, whose veracity none who know them doubt of.

She was born in March, 1731. About the latter end of April, or beginning
of May, 1735, she was greatly affected by the talk of her brother, who
had been hopefully converted a little before, at about eleven years of
age, and then seriously talked to her about the great things of
religion. Her parents did not know of it at that time, and were not
wont, in the counsels they gave to their children, particularly to
direct themselves to her, being so young, and, as they supposed, not
capable of understanding. But after her brother had talked to her, they
observed her very earnestly listen to the advice they gave to the other
children; and she was observed very constantly to retire, several times
in a day, as was concluded, for secret prayer. She grew more and more
engaged in religion, and was more frequent in her closet; till at last
she was wont to visit it five or six times a day: and was so engaged in
it, that nothing would at any time divert her from her stated closet
exercises. Her mother often observed and watched her, when such things
occurred as she thought most likely to divert her, either by putting it
out of her thoughts, or otherwise engaging her inclinations; but never
could observe her to fail. She mentioned some very remarkable instances.

She once of her own accord spake of her unsuccessfulness,

Re: Adding a control from a different AppDomain... how?

am 15.01.2008 23:57:34 von ThunderMusic

passed in sleep, we
have on our own admission no idea of truth, whatever we may imagine. As all
our intuitions are, then, illusions, who knows whether the other half of our
life, in which we think we are awake, is not another sleep a little
different from the former, from which we awake when we suppose ourselves
asleep?

And who doubts that, if we dreamt in company, and the dreams chanced to
agree, which is common enough, and if we were always alone when awake, we
should believe that matters were reversed? In short, as we often dream that
we dream, heaping dream upon dream, may it not be that this half of our
life, wherein we think ourselves awake, is itself only a dream on which the
others are grafted, from which we wake at death, during which we have as few
principles of truth and good as during natural sleep, these different
thoughts which disturb us being perhaps only illusions like the flight of
time and the vain fancies of our dreams?

These are the chief arguments on one side and the other.

I omit minor ones, such as the sceptical talk against the impressions of
custom, education, manners, country and the like. Though these influence the
majority of common folk, who dogmatise only on shallow foundations, they are
upset by the least breath of the sceptics. We have only to see their books
if we are not sufficiently convinced of this, and we shall very quickly
become so, perhaps too much.

I notice the only strong point of the dogmatists, namely, that, speaking in
good faith and sincerely, we cannot doubt natural principles. Against this
the sceptics set up in one word the uncertainty of our origin, which
includes that of our nature. The dogmatists have been trying to answer this
objection ever since the world began.

So there is open war among men, in which each must take a part and side
either with dogmatism or scepticism. For he who thinks to remain neutral is
above

Re: Adding a control from a different AppDomain... how?

am 16.01.2008 00:42:11 von londoncalling

we are aware of the passage of time, we measure it; and in fact we
act as if we were awake. So that half of our life being passed in sleep, we
have on our own admission no idea of truth, whatever we may imagine. As all
our intuitions are, then, illusions, who knows whether the other half of our
life, in which we think we are awake, is not another sleep a little
different from the former, from which we awake when we suppose ourselves
asleep?

And who doubts that, if we dreamt in company, and the dreams chanced to
agree, which is common enough, and if we were always alone when awake, we
should believe that matters were reversed? In short, as we often dream that
we dream, heaping dream upon dream, may it not be that this half of our
life, wherein we think ourselves awake, is itself only a dream on which the
others are grafted, from which we wake at death, during which we have as few
principles of truth and good as during natural sleep, these different
thoughts which disturb us being perhaps only illusions like the flight of
time and the vain fancies of our dreams?

These are the chief arguments on one side and the other.

I omit minor ones, such as the sceptical talk against the impressions of
custom, education, manners, country and the like. Though these influence the
majority of common folk, who dogmatise only on shallow foundations, they are
u

Re: Adding a control from a different AppDomain... how?

am 16.01.2008 00:45:38 von mvp

exults in showing how unreasonable this is; but it is very
reasonable. Savages laugh at an infant king.

3. In being offended at a blow, or in desiring glory so much. But it is very
desirable on account of the other essential goods which are joined to it;
and a man who has received a blow, without resenting it, is overwhelmed with
taunts and indignities.

4. In working for the uncertain; in sailing on the sea; in walking over a
plank.

325. Montaigne is wrong. Custom should be followed only because it is
custom, and not because it is reasonable or just. But people follow it for
this sole reason, that they think it just. Otherwise they would follow it no
longer, although it were the custom; for they will only submit to reason or
justice. Custom without this would pass for tyranny; but the sovereignty of
reason and justice is no more tyrannical than that of desire. They are
principles natural to man.

It would, therefore, be right to obey laws and customs, because they are
laws; but we should know that there is neither truth nor justice to
introduce into them, that we know nothing of these, and so must follow what
is accepted. By this means we would never depart from them. But people
cannot accept this doctrine; and, as they believe that truth can be found,
and that it exists in law and custom, they believe them and take their
antiquity as a proof of their truth, and not simply of their authority apart
from truth. Thus they obey laws, but they are liable to revolt when these

Re: Adding a control from a different AppDomain... how?

am 16.01.2008 01:28:50 von londoncalling

a sign of error than a miracle is a sign of truth.
Therefore a miracle cannot lead into error.

But, apart from schism, error is not so obvious as a miracle is obvious.
Therefore a miracle could lead into error.

Ubi est Deus tuus?209 Miracles show Him, and are a light.

847. One of the anthems for Vespers at Christmas: Exortum est in tenebris
lumen rectis corde.[210]

848. If the compassion of God is so great that He instructs us to our
benefit, even when He hides Himself, what light ought we not to expect from
Him when He reveals Himself?

849. Will Est et non est.211 be received in faith itself as well as in
miracles? And if it is inseparable in the others...

When Saint Xavier works miracles. Saint Hilary. "Ye wretches, who oblige us
to speak of miracles."

Unjust judges, make not your own laws on the moment; judge by those which
are established, and by yourselves. Vae qui conditis leges iniquas.212

Miracles endless, false.

In order to weaken your adversaries, you disarm the whole Church.

If they say that our salvation depends upon God, they are "heretics." If
they

Re: Adding a control from a different AppDomain... how?

am 16.01.2008 02:19:31 von ThunderMusic

in its fury; and while wicked men live here, it
is like fire pent up by God's restraints, whereas if it were let loose,
it would set on fire the course of nature; and as the heart is now a
sink of sin, so if sin was not restrained, it would immediately turn the
soul into fiery oven, or a furnace of fire and brimstone.

It is no security to wicked men for one moment, that there are no
visible means of death at hand. It is no security to a natural man, that
he is now in health, and that he does not see which way he should now
immediately go out of the world by any accident, and that there is no
visible danger in any respect in his circumstances. The manifold and
continual experience of the world in all ages, shows this is no
evidence, that a man is not on the very brink of eternity, and that the
next step will not be into another world. The unseen, unthought-of ways
and means of persons going suddenly out of the world are innumerable and
inconceivable. Unconverted men walk over the pit of hell on a rotten
covering, and there are innumerable places in this covering so weak that
they will not bear their weight, and these places are not seen. The
arrows of death fly unseen at noon-day; the sharpest sight cannot
discern them. God has so many different unsearchable ways of taking
wicked men out of the world and sending them to hell, that there is
nothing to make it appear, that God had need to be at the expense of a
miracle, or go out of the ordinary course of his providence, to destroy
any wicked man, at any moment. All the means that there are of sinners
going out of the world, are so in God's h