appdomain

  • Thread starter Thread starter Alan Zhong
  • Start date Start date
A

Alan Zhong

is it true that more than one process can be run within one appdomain?
if yes, how does it work (in code)?
i use AppDomain.CurrentDomain.ExecuteAssembly(....) twice in a row, the
second one executes after the first one... should i use threads?
thankx.
from alan.
 
Alan Zhong said:
is it true that more than one process can be run within one appdomain?
Click to expand...

No. There can be multiple AppDomains in a process, but any AppDomain
only lives within a single process.
if yes, how does it work (in code)?
i use AppDomain.CurrentDomain.ExecuteAssembly(....) twice in a row, the
second one executes after the first one... should i use threads?
Click to expand...

If you want things to execute concurrently, then yes, you need to use
threads (or multiple processes).
 
Processes are OS objects, that means they are created and managed by the OS
but they are NOT hosted in AD's.
AD's are CLR managed objects, they are unknown to the OS and aren't even
related (although they have similarities), each OS process that hosts the
CLR, consists of multiple Application Domains created by the CLR and by user
code.

During the initialization, the CLR creates by default the following AD's:
- The 'system' domain,
- the 'shared' domain,
- and the 'default' domain.
The 'default' domain is the first domain in the process that actually runs
managed user code, that means that all assemblies loaded at run-time are
loaded into the default domain (and possibly the shared AD) unless you
create addtional domains to load/run assemblies.
The call to ExecuteAssembly is a sychronous call, that means that you'll
have to create separate threads to execute multiple ExecuteAssembly()
methods.

Willy.
 
During the initialization, the CLR creates by default the following AD's:
- The 'system' domain,
- the 'shared' domain,
- and the 'default' domain.
The 'default' domain is the first domain in the process that actually runs
managed user code, that means that all assemblies loaded at run-time are
loaded into the default domain (and possibly the shared AD) unless you
create addtional domains to load/run assemblies.
Click to expand...

What are the shared and system appdomains used for (and where can I get more
info about them)? Are there any mechanisms for accessing them? Thanks
 
David Levine said:
What are the shared and system appdomains used for (and where can I get
more info about them)? Are there any mechanisms for accessing them?
Thanks
Click to expand...

Both AD's are CLR internal abstractions, that means they aren't visible from
managed code.
Some more detailed info is found here:
http://msdn.microsoft.com/msdnmag/issues/05/05/JITCompiler/default.aspx
while the following explains how Shared Domain and Domain Neutral assemblies
relate:
http://blogs.msdn.com/junfeng/archive/2004/08/05/208375.aspx

Note that the system domain is used by the CLR to store types that don't
really belong to any other domain, amongst these types are the Platform
Invoke thunks and the COM interop dynamically generated CCW and RCW's.

Willy.
 
Back
Top