In the Common Language Runtime, an application domain is a mechanism (similar to a process in an operating system) used to isolate executed software applications from one another so that they do not affect each other. Each application domain has their own virtual address space which scopes the resources for the application domain using that address space.
A Common Language Runtime application domain is contained within an operating system process. A process may contain many application domains. This carries major advantages:
An application domain represents isolation/scoping unit for a .NET
application. .NET allows multiple applications to be loaded in a single process. It achieves this by loading each application in its own independent application domain.
Each application domain is isolated from all other application domains. You can think of application domains as lightweight processes with a process. This is more efficient than creating a separate process for each application and provides the same benefit (isolation).
Use System.AppDomain to create application domains programmatically. CLR itself runs in an application domain called the default domain.
A Common Language Runtime application domain is contained within an operating system process. A process may contain many application domains. This carries major advantages:
- There is lower system cost.
- Multiple threads can exist within a single application domain.
- The application in a domain can be stopped without affecting the state of another domain in the same process.
- A fault or exception in one domain does not affect an application in another domain or crash the entire process that hosts the domains.
- Configuration information is part of a domain's scope, not the scope of the process.
- Each domain can be assigned different security access levels, all within a single process.
- Code in one domain cannot directly access code in another.
An application domain represents isolation/scoping unit for a .NET
application. .NET allows multiple applications to be loaded in a single process. It achieves this by loading each application in its own independent application domain.
Each application domain is isolated from all other application domains. You can think of application domains as lightweight processes with a process. This is more efficient than creating a separate process for each application and provides the same benefit (isolation).
Use System.AppDomain to create application domains programmatically. CLR itself runs in an application domain called the default domain.
The common language runtime is the execution engine for .NET Framework applications.
It provides a number of services, including the following:
It provides a number of services, including the following:
- Code management loading and execution
- Application memory isolation
- Verification of type safety
- Conversion of IL to native code
- Access to metadata
- Managing memory for managed objects
- Enforcement of code access security
- Exception handling, including cross-language exceptions
- Interoperation between managed code, COM objects, and pre-existing DLLs like unmanaged code and data
- Automation of object layout
- Support for developer services like profiling, debugging
Any COM component you have deployed today can be used from managed code, and in common cases the adaptation is totally automatic.
Specifically, COM components are accessed from the .NET Framework by use of a runtime callable wrapper (RCW). This wrapper turns the COM interfaces exposed by the COM component into .NET Framework-compatible interfaces. For OLE automation interfaces, the RCW can be generated automatically from a type library. For non-OLE automation interfaces, a developer may write a custom RCW and manually map the types exposed by the COM interface to .NET Framework-compatible types.
Managed types you build today can be made accessible from COM, and in the common case the configuration is totally automatic. There are certain new features of the managed development environment that are not accessible from COM. For example, static methods and parameterized constructors cannot be used from COM. In general, it is a good idea to decide in advance who the intended user of a given type will be. If the type is to be used from COM, you may be restricted to using those features that are COM accessible.
Depending on the language used to write the managed type, it may or may not be visible by default.
Specifically, .NET Framework components are accessed from COM by using a COM callable wrapper (CCW). This is similar to an RCW (see previous question), but works in the opposite direction. Again, if the .NET Framework development tools cannot automatically generate the wrapper, or if the automatic behavior is not what you want, a custom CCW can be developed.
Specifically, COM components are accessed from the .NET Framework by use of a runtime callable wrapper (RCW). This wrapper turns the COM interfaces exposed by the COM component into .NET Framework-compatible interfaces. For OLE automation interfaces, the RCW can be generated automatically from a type library. For non-OLE automation interfaces, a developer may write a custom RCW and manually map the types exposed by the COM interface to .NET Framework-compatible types.
Managed types you build today can be made accessible from COM, and in the common case the configuration is totally automatic. There are certain new features of the managed development environment that are not accessible from COM. For example, static methods and parameterized constructors cannot be used from COM. In general, it is a good idea to decide in advance who the intended user of a given type will be. If the type is to be used from COM, you may be restricted to using those features that are COM accessible.
Depending on the language used to write the managed type, it may or may not be visible by default.
Specifically, .NET Framework components are accessed from COM by using a COM callable wrapper (CCW). This is similar to an RCW (see previous question), but works in the opposite direction. Again, if the .NET Framework development tools cannot automatically generate the wrapper, or if the automatic behavior is not what you want, a custom CCW can be developed.
There are two aspects to in-process communication: between contexts within a single application domain, or across application domains. Between contexts in the same application domain, proxies are used as an interception mechanism. No marshaling/serialization is involved. When crossing application domains, we do marshaling/serialization using the runtime binary protocol.
Cross-process communication uses a pluggable channel and formatter protocol, each suited to a specific purpose.
If the developer specifies an endpoint using the tool soapsuds.exe to generate a metadata proxy, HTTP channel with SOAP formatter is the default.
If a developer is doing explicit remoting in the managed world, it is necessary to be explicit about what channel and formatter to use. This may be expressed administratively, through configuration files, or with API calls to load specific channels. Options are:
HTTP channel w/ SOAP formatter (HTTP works well on the Internet, or anytime traffic must travel through firewalls)
TCP channel w/ binary formatter (TCP is a higher performance option for local-area networks (LANs)
When making transitions between managed and unmanaged code, the COM infrastructure (specifically, DCOM) is used for remoting. In interim releases of the CLR, this applies also to serviced components (components that use COM+ services). Upon final release, it should be possible to configure any remotable component.
Distributed garbage collection of objects is managed by a system called "leased based lifetime." Each object has a lease time, and when that time expires, the object is disconnected from the remoting infrastructure of the CLR. Objects have a default renew time-the lease is renewed when a successful call is made from the client to the object. The client can also explicitly renew the lease.
Cross-process communication uses a pluggable channel and formatter protocol, each suited to a specific purpose.
If the developer specifies an endpoint using the tool soapsuds.exe to generate a metadata proxy, HTTP channel with SOAP formatter is the default.
If a developer is doing explicit remoting in the managed world, it is necessary to be explicit about what channel and formatter to use. This may be expressed administratively, through configuration files, or with API calls to load specific channels. Options are:
HTTP channel w/ SOAP formatter (HTTP works well on the Internet, or anytime traffic must travel through firewalls)
TCP channel w/ binary formatter (TCP is a higher performance option for local-area networks (LANs)
When making transitions between managed and unmanaged code, the COM infrastructure (specifically, DCOM) is used for remoting. In interim releases of the CLR, this applies also to serviced components (components that use COM+ services). Upon final release, it should be possible to configure any remotable component.
Distributed garbage collection of objects is managed by a system called "leased based lifetime." Each object has a lease time, and when that time expires, the object is disconnected from the remoting infrastructure of the CLR. Objects have a default renew time-the lease is renewed when a successful call is made from the client to the object. The client can also explicitly renew the lease.
Display metadata of one of your .NET programs or libraries by the use of the ILDASM tool:C# prompt > ildasm app1.exe
We can see the assembly's metadata with all the methods and types in a tree representation. If we click on ' M A N I F E S T ' we get a window, which shows the manifest information. Even if there are a lot of non well readable lines, we are able to identify version information and all the referenced assemblies used to run the displayed executable or library.
Why does the tool we have used right now call ' Intermediate Language Disassembler ' ? Just bring back into our minds that if we compile sources, for instance with the CSharp Compiler (CSC) or any other .NET language compiler, we won't get machine code executable on a computer. Instead we get Microsoft Intermediate Language (MSIL) or shortened to Intermediate Language (IL) stored as an EXE file. To get machine code and to run the EXE we need the Common Language Runtime (CLR) part of the .NET installation somewhere on our computer.