Re: Question on AppDomain and Thread

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Leon,

When you create a new AppDomain, objects you created in there using say
AppDomain.CreateInstanctAndUnwrap() run in the same thread as the caller
is
that correct?

When you invoke a method on the object it will be invoked on the current
thread in the AppDomain in which the object was created.

If so, how could I create an AppDomain having its distinct thread? In
particularly, I would like to create several AppDomains each with its own
STA
so that I can have UI object living in them and they are running
concurrently.

AppDomains don't own threads. They are shared amongst all AppDomains in the
process, but a single thread will only execute in one AppDomain at a time.

To execute code concurrently and within a different AppDomain, create a
background thread to invoke an object's method or provide asynchronous
methods on your object (preferred). If the object is a MarshalByRefObject
obtained from a different AppDomain then the code will execute within that
AppDomain, concurrently with the main thread of your application, when
calling on a background thread just as it would an object within the same
AppDomain as the caller.

Kind of like transplanting an unmanaged architecture involving several ole
automation servers (executables with their independent threads) to managed
world using one executables but they are mapped to AppDomain partitioning.
But each AppDomain must have its own thread with its own message pump so
that
WinForm objects can live there.

I'm not sure what value there would be in managing multiple interface
components in multiple AppDomains, but I don't think it's possible anyway.
Controls can only be manipulate on the thread in which they were created.
Therefore, you may be able to have Forms within different AppDomains running
simultaneously, but I doubt that you'll be able to make them children of the
same MDI container, and you won't be able to have controls from different
AppDomains on the same Form. If you were intending to do drag & drop
operations between different Forms, for example, that wouldn't work either
unless the control was recreated in the target AppDomain's thread.

Normally, an application has just one GUI thread and invokes long-running
processes on background threads. If the long-running processes need
isolation from the default AppDomain then you can execute them within a
separate AppDomain, asynchronously, but all GUI components should be created
on the same thread (the one that started the message loop with a call to
Application.Run).

--
Dave Sexton


.

Relevant Pages

  • Re: Running process in memory
    ... portion of a .Net assembly, then you could theoretically create a new ... AppDomain, then use .LoadAssembly() to load it, and then invoke the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: My own autoupdater - problem
    ... Next, however, while trying to install the new version, I run ... open an explorer and b) let wceload.exe execute the cab-file ... the autoupdate and the core app in two different appdomains. ... I mean, having the main appdomain which checks for updates, download them ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Preloading assemblies into an AppDomain I create
    ... application B (by using the AppDomain functionality). ... assemblies for an application and thus make that application start-up ... rather than just to execute application B directly. ... that AppDomain - but I'm still seeing slower performance. ...
    (microsoft.public.dotnet.languages.csharp)
  • Execute a dynamic Assembly in a child AppDomain
    ... We use CSharpCodeProvider to create and execute an assembly at ... It says that I need to execute the assembly in a child AppDomain ... specify which AppDomain I want to compile into. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: AppDomain and Reflection
    ... locations for the appDomain to use. ... The shadowfiles and the original file is ... You have to execute the assembly and type loading code in the remote ...
    (microsoft.public.dotnet.framework.windowsforms)