Application domain

This article is about CLI application domains. For other application domains, see Domain (software engineering).

An application domain is a mechanism (similar to a process in an operating system) used within the Common Language Infrastructure (CLI) to isolate executed software applications from one another so that they do not affect each other. Each application domain has its own virtual address space which scopes the resources for the application domain using that address space.

Creating multiple application domains in the same process is not possible in .NET Core and .NET 5+.[1]

## Contents

* 1 Properties
* 2 Inter-domain communications
* 3 Managed code
* 4 References

## Properties

A CLI application domain is contained within an operating system process. A process may contain many application domains. Application domains have isolation properties similar to that of operating system processes:

* Multiple threads can exist within a single application domain.
* An application within 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.
* Code in one domain cannot directly access code in another.

In this sense, a CLI is like a mini-operating system. It runs a single process that contains a number of sub-processes, or application domains.

The advantage of application domains is that running multiple application domains may require fewer resources, such as memory, than running multiple operating system processes. Communication between domains still requires marshalling, so the overheads can be closer to using multiple processes than to communicating within a single domain.

## Inter-domain communications

Direct communication cannot be achieved across application domains. However, application domains can still talk to each other by passing objects via marshalling by value (unbound objects), marshalling by reference through a proxy (application-domain-bound objects). There is a third type of object called a context-bound object which can be marshalled by reference across domains and also within the context of its own application domain. Because of the verifiable type-safety of managed code, a CLI can provide fault isolation between domains at a much lower cost than an operating system process can. The static type verification used for isolation does not require the same process switches or hardware ring transitions that an operating system process requires.

## Managed code

Application domains are a purely managed code concept. Any included native/unmanaged code (e.g., C++) is largely unaware of them. Static variables seem to be shared across domains, callbacks can be problematic, and any memory corruption bugs in one domain is likely to corrupt other domains.

## References

1. ↑ ".NET Framework technologies unavailable on .NET Core and .NET 5+" (in en-us). https://docs.microsoft.com/en-us/dotnet/core/porting/net-framework-tech-unavailable.

* Microsoft Developer Network page on application domains
* Unmanaged callbacks across AppDomains

* v
* t
* e

.NET Framework

* Version history
* .NET strategy

Architecture|

* Common Language Runtime (CLR)
* COM Interop
* Framework Class Library (FCL)

Components|

* ADO.NET
* Entity Framework
* ASP.NET
* Web Forms
* AJAX
* Core
* Dynamic Data
* MVC
* Razor
* ClickOnce
* Dynamic Language Runtime
* Extensible Application Markup Language (XAML)
* Language Integrated Query (LINQ)
* Managed Extensibility Framework
* Microsoft Silverlight
* Microsoft XNA
* Parallel Extensions
* Windows Communication Foundation (WCF)
* WCF Data Services
* Windows Forms (WinForms)
* Windows Identity Foundation (WIF)
* Windows Presentation Foundation (WPF)
* Windows Workflow Foundation (WF)
* .NET Remoting

Tools|

| Decompilers|

* .NET Reflector
* dotPeek

|

Obfuscators|

* Dotfuscator
* SmartAssembly
* CodeArmor

Misc|

* CLR Profiler
* ILAsm
* .NET Compiler Platform
* Native Image Generator (NGen)
* XAMLPad

IDEs|

* Visual Studio
* Blend
* Express
* MonoDevelop
* SharpDevelop
* Xamarin Studio

Organizations|

* .NET Foundation
* Microsoft
* Xamarin

* Category
* List

* v
* t
* e

Common Language Infrastructure

Architecture|

* Application domain
* Code Access Security
* Common Intermediate Language (CIL)
* CIL instructions
* Common Type System (CTS)
* Platform Invocation Services (P/Invoke)
* Virtual Execution System (VES)

Components|

* Assembly
* Delegate
* Global Assembly Cache (GAC)
* Manifest
* Metadata

Standard
Libraries|

| Kernel Profile|

* Base Class Library (BCL)
* Runtime Infrastructure Library

|

Compact Profile|

* Network Library
* Reflection Library
* XML Library

* Extended Array Library
* Extended Numerics Library
* Parallel Library
* Vararg Library

Implementations|

| Microsoft|

* .NET Framework
* .NET Compact Framework
* .NET Micro Framework
* Shared Source Common Language Infrastructure

|

Other|

* .NET Core
* Mono
* Xamarin.iOS
* Xamarin.Android
* Xamarin.Mac
* Portable.NET

Languages|

| Microsoft|

* C#
* Visual Basic .NET
* C++/CLI
* Managed
* F#
* Q#
* J#
* JScript .NET
* PowerShell

|

Other|

* Axum
* A#
* Boo
* Cobra
* IronScheme
* IronLisp
* IronPython
* IronRuby
* Nemerle
* Oxygene
* Phalanger
* P#
* Scala

Comparison|

* C# and Java
* C# and Visual Basic .NET
* Java and .NET platforms
* Visual Basic and Visual Basic .NET

Organizations|

* .NET Foundation
* DotGNU
* Microsoft
* Xamarin

0.00

(0 votes)

Original source: https://en.wikipedia.org/wiki/Application domain. Read more

|

Retrieved from "https://handwiki.org/wiki/index.php?title=Application_domain&oldid=4154032"
*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template