アプリケーション ドメインApplication Domains

オペレーティング システムやランタイム環境では、通常、複数のアプリケーションがなんらかの形で分離されています。Operating systems and runtime environments typically provide some form of isolation between applications. たとえば、Windows ではプロセスを使用してアプリケーションが分離されています。For example, Windows uses processes to isolate applications. このような分離は、あるアプリケーションで実行されているコードが、関係のない別のアプリケーションに悪影響をもたらさないようにするために必要です。This isolation is necessary to ensure that code running in one application cannot adversely affect other, unrelated applications.

アプリケーション ドメインは、セキュリティ、信頼性、バージョン管理のための、またアセンブリをアンロードするための分離の境界を提供します。Application domains provide an isolation boundary for security, reliability, and versioning, and for unloading assemblies. 通常、アプリケーション ドメインは、アプリケーションの実行前に共通言語ランタイムの起動を行うランタイム ホストによって作成されます。Application domains are typically created by runtime hosts, which are responsible for bootstrapping the common language runtime before an application is run.

このセクションのトピックでは、アプリケーション ドメインを使用してアセンブリ間を分離する方法について説明します。The topics in this section of the documentation explain how to use application domains to provide isolation between assemblies.

この概要は、次のセクションで構成されています。This overview contains the following sections:

アプリケーションを分離する利点The Benefits of Isolating Applications

これまで、同じコンピューター上で実行される複数のアプリケーションを分離するためには、プロセス境界が使用されていました。Historically, process boundaries have been used to isolate applications running on the same computer. この場合、各アプリケーションが独立のプロセスに読み込まれることで、アプリケーションは同じコンピューター上で実行されるほかのアプリケーションから分離されます。Each application is loaded into a separate process, which isolates the application from other applications running on the same computer.

アプリケーションが分離されるのは、メモリ アドレスがプロセスごとの相対アドレスになっていたためです。つまり、メモリ ポインターをあるプロセスから別のプロセスに渡しても、そのポインターが渡された側のプロセスでは機能しませんでした。The applications are isolated because memory addresses are process-relative; a memory pointer passed from one process to another cannot be used in any meaningful way in the target process. また、2 つのプロセス間で直接呼び出しを行うこともできませんでした。In addition, you cannot make direct calls between two processes. 代わりに間接的な呼び出しを行う場合は、プロキシを使用する必要がありました。Instead, you must use proxies, which provide a level of indirection.

マネージド コードは、実行される前に必ず検査プロセスに渡されます (管理者が検査を省略する許可をコードに与えた場合は除きます)。Managed code must be passed through a verification process before it can be run (unless the administrator has granted permission to skip the verification). 検査プロセスでは、そのコードが無効なメモリ アドレスにアクセスしたり、コードが実行されるプロセスの正常実行を妨げる原因となる動作を実行したりすることがないかどうかを確認します。The verification process determines whether the code can attempt to access invalid memory addresses or perform some other action that could cause the process in which it is running to fail to operate properly. 検査テストを通過したコードは、タイプ セーフであると言われます。Code that passes the verification test is said to be type-safe. コードがタイプ セーフかどうかを検査するこのような機能があるため、共通言語ランタイムでは、プロセス境界と同等の高度な分離レベルを実現しながら、パフォーマンスへの影響は大幅に低く抑えることができます。The ability to verify code as type-safe enables the common language runtime to provide as great a level of isolation as the process boundary, at a much lower performance cost.

アプリケーション ドメインは、共通言語ランタイムがアプリケーション間を分離するために使用できる、より安全で柔軟性に富んだ処理単位となります。Application domains provide a more secure and versatile unit of processing that the common language runtime can use to provide isolation between applications. 個別のプロセスを使用する場合と同じ分離レベルを実現しながら、しかしプロセス間での呼び出しやプロセスの切り替えによるオーバーヘッドを生じることもなく、1 つのプロセス内で複数のアプリケーション ドメインを実行できます。You can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes. 1 つのプロセス内で複数のアプリケーションを実行できるため、サーバーのスケーラビリティが飛躍的に向上します。The ability to run multiple applications within a single process dramatically increases server scalability.

アプリケーションの分離は、アプリケーションのセキュリティを考えるうえでも重要です。Isolating applications is also important for application security. たとえば、複数のコントロールが互いのデータやリソースにアクセスできないようにして、1 つのブラウザー プロセスで複数の Web アプリケーションのコントロールを実行できます。For example, you can run controls from several Web applications in a single browser process in such a way that the controls cannot access each other's data and resources.

アプリケーション ドメインによる分離には、次の利点があります。The isolation provided by application domains has the following benefits:

  • 1 つのアプリケーションで発生したエラーが、ほかのアプリケーションに影響することはありません。Faults in one application cannot affect other applications. タイプ セーフなコードではメモリ フォールトが発生しないため、アプリケーション ドメインを使用することで、1 つのドメインで実行されているコードが同じプロセス内のほかのアプリケーションに影響することが確実になくなります。Because type-safe code cannot cause memory faults, using application domains ensures that code running in one domain cannot affect other applications in the process.

  • プロセス全体を停止せずに、個々のアプリケーションを停止できます。Individual applications can be stopped without stopping the entire process. アプリケーション ドメインを使用すると、1 つのアプリケーション内で実行されているコードをアンロードできます。Using application domains enables you to unload the code running in a single application.

    注意

    個々のアセンブリや型はアンロードできません。You cannot unload individual assemblies or types. アンロードできるのはドメイン全体だけです。Only a complete domain can be unloaded.

  • 1 つのアプリケーションで実行されているコードは、ほかのアプリケーションのコードやリソースに直接アクセスできません。Code running in one application cannot directly access code or resources from another application. 共通言語ランタイムでは、異なるアプリケーション ドメインにあるオブジェクト間での直接呼び出しを禁止することで分離を実現しています。The common language runtime enforces this isolation by preventing direct calls between objects in different application domains. ドメイン間で渡されるオブジェクトは、コピーされるか、またはプロキシ経由でアクセスされます。Objects that pass between domains are either copied or accessed by proxy. オブジェクトがコピーされる場合、オブジェクトの呼び出しはローカル呼び出しです。If the object is copied, the call to the object is local. つまり、呼び出し元と参照先オブジェクトの両方が、同じアプリケーション ドメイン内にあります。That is, both the caller and the object being referenced are in the same application domain. オブジェクトがプロキシ経由でアクセスされる場合は、オブジェクトの呼び出しはリモート呼び出しです。If the object is accessed through a proxy, the call to the object is remote. この場合は、呼び出し元と参照先オブジェクトが別のアプリケーション ドメイン内にあります。In this case, the caller and the object being referenced are in different application domains. ドメイン間呼び出しでは、2 つのプロセス間や 2 台のコンピューター間での呼び出しと同じリモート呼び出しインフラストラクチャが使用されます。Cross-domain calls use the same remote call infrastructure as calls between two processes or between two machines. そのため、メソッドの呼び出しが正しく JIT コンパイルされるように、参照先オブジェクトのメタデータが両方のアプリケーション ドメインから利用できることが必要です。As such, the metadata for the object being referenced must be available to both application domains to allow the method call to be JIT-compiled properly. 呼び出し元のドメインが呼び出し先オブジェクトのメタデータにアクセスできない場合、コンパイルは System.IO.FileNotFound という例外が発生して失敗する可能性があります。If the calling domain does not have access to the metadata for the object being called, the compilation might fail with an exception of type System.IO.FileNotFound. 詳細については、「リモート オブジェクト」を参照してください。See Remote Objects for more details. ドメイン間でオブジェクトにアクセスする方法は、アクセス対象のオブジェクトによって決まります。The mechanism for determining how objects can be accessed across domains is determined by the object. 詳細については、「System.MarshalByRefObject」を参照してください。For more information, see System.MarshalByRefObject.

  • コードが影響する範囲は、そのコードが実行されるアプリケーションによって決まります。The behavior of code is scoped by the application in which it runs. つまり、アプリケーション ドメインは、アプリケーションのバージョン ポリシー、アクセス対象となるリモート アセンブリの位置、ドメインに読み込まれるアセンブリの場所に関する情報などの構成設定を提供します。In other words, the application domain provides configuration settings such as application version policies, the location of any remote assemblies it accesses, and information about where to locate assemblies that are loaded into the domain.

  • コードに与えられるアクセス許可は、そのコードが実行されるアプリケーション ドメインによって制御されます。Permissions granted to code can be controlled by the application domain in which the code is running.

アプリケーション ドメインとアセンブリApplication Domains and Assemblies

ここでは、アプリケーション ドメインとアセンブリの関係について説明します。This topic describes the relationship between application domains and assemblies. アセンブリに含まれるコードを実行する前に、そのアセンブリをアプリケーション ドメインに読み込む必要があります。You must load an assembly into an application domain before you can execute the code it contains. 通常のアプリケーションを実行すると、複数のアセンブリがアプリケーション ドメインに読み込まれます。Running a typical application causes several assemblies to be loaded into an application domain.

アセンブリが読み込まれる方法によって、そのアセンブリの Just-In-Time (JIT) コンパイル コードをプロセス内の複数のアプリケーション ドメインで共有できるかどうか、およびアセンブリをプロセスからアンロードできるかどうかが決まります。The way an assembly is loaded determines whether its just-in-time (JIT) compiled code can be shared by multiple application domains in the process, and whether the assembly can be unloaded from the process.

  • アセンブリがドメインに中立として読み込まれる場合は、同じセキュリティ許可セットを共有するすべてのアプリケーション ドメインが同じ JIT コンパイル コードを共有できるため、アプリケーションに必要なメモリを削減できます。If an assembly is loaded domain-neutral, all application domains that share the same security grant set can share the same JIT-compiled code, which reduces the memory required by the application. ただし、アセンブリをプロセスからアンロードできなくなります。However, the assembly can never be unloaded from the process.

  • アセンブリがドメインに中立として読み込まれない場合は、そのアセンブリが読み込まれる各アプリケーション ドメインで、そのアセンブリを JIT でコンパイルする必要があります。If an assembly is not loaded domain-neutral, it must be JIT-compiled in every application domain in which it is loaded. ただし、アセンブリが読み込まれているアプリケーション ドメインをすべてアンロードすることで、プロセスからアセンブリをアンロードできます。However, the assembly can be unloaded from the process by unloading all the application domains in which it is loaded.

ランタイム ホストは、ランタイムをプロセスに読み込むときに、アセンブリをドメインに中立なアセンブリとして読み込むかどうかを決定します。The runtime host determines whether to load assemblies as domain-neutral when it loads the runtime into a process. マネージド アプリケーションの場合は、LoaderOptimizationAttribute 属性をプロセスのエントリ ポイント メソッドに適用し、関連付けられた LoaderOptimization 列挙体から値を指定します。For managed applications, apply the LoaderOptimizationAttribute attribute to the entry-point method for the process, and specify a value from the associated LoaderOptimization enumeration. 共通言語ランタイムをホストするアンマネージ アプリケーションの場合は、CorBindToRuntimeEx 関数メソッドを呼び出すときに適切なフラグを指定します。For unmanaged applications that host the common language runtime, specify the appropriate flag when you call the CorBindToRuntimeEx Function method.

アセンブリをドメインに中立として読み込むかどうかに関して、次の 3 つのオプションがあります。There are three options for loading domain-neutral assemblies:

  • LoaderOptimization.SingleDomain では、常にドメインに中立として読み込まれる Mscorlib を除き、どのアセンブリもドメインに中立として読み込まれません。LoaderOptimization.SingleDomain loads no assemblies as domain-neutral, except Mscorlib, which is always loaded domain-neutral. この設定は、ホストがプロセス内で 1 つのアプリケーションだけを実行する場合に一般的に使用されるため、シングル ドメインと呼ばれます。This setting is called single domain because it is commonly used when the host is running only a single application in the process.

  • LoaderOptimization.MultiDomain では、すべてのアセンブリがドメインに中立として読み込まれます。LoaderOptimization.MultiDomain loads all assemblies as domain-neutral. この設定は、同じコードを実行する複数のアプリケーション ドメインが 1 つのプロセス内に存在する場合に使用します。Use this setting when there are multiple application domains in the process, all of which run the same code.

  • LoaderOptimization.MultiDomainHost では、厳密な名前が付いたアセンブリとそのすべての依存関係がグローバル アセンブリ キャッシュにインストールされている場合に、それらのアセンブリがドメインに中立として読み込まれます。LoaderOptimization.MultiDomainHost loads strong-named assemblies as domain-neutral, if they and all their dependencies have been installed in the global assembly cache. その他のアセンブリは、それらが読み込まれる各アプリケーション ドメインで個別に読み込まれ、JIT でコンパイルされるため、プロセスからアンロードできます。Other assemblies are loaded and JIT-compiled separately for each application domain in which they are loaded, and thus can be unloaded from the process. この設定は、同じプロセスで複数のアプリケーションが実行されている場合、または多数のアプリケーション ドメインで共有されているアセンブリと、プロセスからアンロードする必要があるアセンブリが混在している場合に使用します。Use this setting when running more than one application in the same process, or if you have a mixture of assemblies that are shared by many application domains and assemblies that need to be unloaded from the process.

LoadFrom クラスの Assembly メソッドを使用して読み込み元を指定して読み込まれたアセンブリ、またはバイト配列を指定する Load メソッドのオーバーロードを使用してイメージから読み込まれたアセンブリについては、JIT コンパイル コードを共有できません。JIT-compiled code cannot be shared for assemblies loaded into the load-from context, using the LoadFrom method of the Assembly class, or loaded from images using overloads of the Load method that specify byte arrays.

Ngen.exe (ネイティブ イメージ ジェネレーター) を使用してネイティブ コードにコンパイルされたアセンブリは、プロセスに最初に読み込まれるときにドメインに中立として読み込まれていれば、アプリケーション ドメイン間で共有できます。Assemblies that have been compiled to native code by using the Ngen.exe (Native Image Generator) can be shared between application domains, if they are loaded domain-neutral the first time they are loaded into a process.

アプリケーションのエントリ ポイントを含むアセンブリの JIT コンパイル コードは、そのすべての依存関係を共有できる場合にだけ共有されます。JIT-compiled code for the assembly that contains the application entry point is shared only if all its dependencies can be shared.

ドメインに中立なアセンブリは、JIT で複数回コンパイルできます。A domain-neutral assembly can be JIT-compiled more than once. たとえば、2 つのアプリケーション ドメインのセキュリティ許可セットが異なっている場合、それらのドメインは同じ JIT コンパイル コードを共有できません。For example, when the security grant sets of two application domains are different, they cannot share the same JIT-compiled code. ただし、JIT コンパイル アセンブリの各コピーは、同じ許可セットを持つ他のアプリケーション ドメインと共有できます。However, each copy of the JIT-compiled assembly can be shared with other application domains that have the same grant set.

アセンブリをドメインに中立として読み込むかどうかを判断する場合は、メモリ使用量の削減とその他のパフォーマンス要因とのトレードオフを考慮する必要があります。When you decide whether to load assemblies as domain-neutral, you must make a tradeoff between reducing memory use and other performance factors.

  • ドメインに中立のアセンブリでは、アセンブリを分離する必要があることから、静的データおよびメソッドにアクセスする速度が遅くなります。Access to static data and methods is slower for domain-neutral assemblies because of the need to isolate assemblies. 静的フィールド内のオブジェクトがドメイン境界を越えて参照されることがないように、アセンブリにアクセスする各アプリケーション ドメインが、静的データのコピーを個別に保持する必要があるためです。Each application domain that accesses the assembly must have a separate copy of the static data, to prevent references to objects in static fields from crossing domain boundaries. その結果、ランタイムには、呼び出し元が静的データまたは静的メソッドの適切なコピーにアクセスできるようにするための追加のロジックが必要となります。As a result, the runtime contains additional logic to direct a caller to the appropriate copy of the static data or method. この追加のロジックのために、呼び出しの処理速度が低下します。This extra logic slows down the call.

  • アセンブリがドメインに中立で読み込まれるときに、アセンブリのすべての依存関係を探し出して読み込む必要があります。これは、ドメインに中立として読み込むことのできない依存関係があると、アセンブリをドメインに中立として読み込むことができなくなるからです。All the dependencies of an assembly must be located and loaded when the assembly is loaded domain-neutral, because a dependency that cannot be loaded domain-neutral prevents the assembly from being loaded domain-neutral.

アプリケーション ドメインとスレッドApplication Domains and Threads

アプリケーション ドメインは、セキュリティ、バージョン管理、信頼性のための、またマネージド コードをアンロードするための分離の境界を形成します。An application domain forms an isolation boundary for security, versioning, reliability, and unloading of managed code. スレッドは、共通言語ランタイムがコードを実行するために使用する、オペレーティング システムの構成です。A thread is the operating system construct used by the common language runtime to execute code. 実行時には、すべてのマネージド コードがアプリケーション ドメインに読み込まれ、1 つまたは複数のマネージド スレッドによって実行されます。At run time, all managed code is loaded into an application domain and is run by one or more managed threads.

アプリケーション ドメインとスレッドとの関係は一対一ではありません。There is not a one-to-one correlation between application domains and threads. 1 つのアプリケーション ドメイン内で一度に複数のスレッドが実行される場合があり、また 1 つのスレッドが 1 つのアプリケーション ドメインに限定されることもありません。Several threads can execute in a single application domain at any given time, and a particular thread is not confined to a single application domain. つまり、スレッドはアプリケーション ドメイン境界を自由に越えることができ、アプリケーション ドメインごとに新しいスレッドが生成されるわけではありません。That is, threads are free to cross application domain boundaries; a new thread is not created for each application domain.

特定の時点に限って見ると、どのスレッドも 1 つのアプリケーション ドメイン内で実行されています。At any given time, every thread executes in an application domain. 特定のアプリケーション ドメインでゼロ、1 つ、または複数のスレッドを実行できます。Zero, one, or multiple threads might be executing in any given application domain. ランタイムは、どのスレッドがどのアプリケーション ドメインで実行されているかを追跡しています。The run time keeps track of which threads are running in which application domains. 任意の時点で、あるスレッドが実行されているドメインを特定するには、Thread.GetDomain メソッドを呼び出します。You can locate the domain in which a thread is executing at any time by calling the Thread.GetDomain method.

アプリケーション ドメインとカルチャApplication Domains and Cultures

CultureInfo オブジェクトによって表されるカルチャは、スレッドに関連付けられます。Culture, which is represented by a CultureInfo object, is associated with threads. CultureInfo.CurrentCulture プロパティを使用すると、現在実行しているスレッドに関連付けられているカルチャを取得できます。Thread.CurrentCulture プロパティを使用すると、現在実行しているスレッドに関連付けられているカルチャを取得または設定できます。You can get the culture that is associated with the currently executing thread by using the CultureInfo.CurrentCulture property, and you can get or set the culture that is associated with the currently executing thread by using the Thread.CurrentCulture property. スレッドに関連付けられているカルチャが Thread.CurrentCulture プロパティを使用して明示的に設定されている場合、スレッドがアプリケーション ドメインの境界を越えても、そのスレッドとの関連付けが維持されます。If the culture that is associated with a thread has been explicitly set by using the Thread.CurrentCulture property, it continues to be associated with that thread when the thread crosses application domain boundaries. それ以外の場合、スレッドに関連付けられるカルチャは、任意の時点でスレッドが実行されているアプリケーション ドメインの CultureInfo.DefaultThreadCurrentCulture プロパティの値によって決まります。Otherwise, the culture that is associated with the thread at any given time is determined by the value of the CultureInfo.DefaultThreadCurrentCulture property in the application domain in which the thread is executing:

  • プロパティの値が null でない場合、プロパティによって返されるカルチャはスレッドに関連付けられます (したがって Thread.CurrentCulture プロパティと CultureInfo.CurrentCulture プロパティによって返されます)。If the value of the property is not null, the culture that is returned by the property is associated with the thread (and therefore returned by the Thread.CurrentCulture and CultureInfo.CurrentCulture properties).

  • プロパティの値が null の場合は、現在のシステム カルチャがスレッドに関連付けられます。If the value of the property is null, the current system culture is associated with the thread.

アプリケーション ドメインを使用したプログラミングProgramming with Application Domains

通常、アプリケーション ドメインは、ランタイム ホストによってプログラムで作成および操作されます。Application domains are usually created and manipulated programmatically by runtime hosts. しかし、アプリケーション プログラムでもアプリケーション ドメインを操作する必要が生じる場合があります。However, sometimes an application program might also want to work with application domains. たとえば、アプリケーション プログラムはアプリケーション コンポーネントをドメインに読み込むことができるため、アプリケーション全体を停止せずにドメイン (およびコンポーネント) をアンロードできます。For example, an application program could load an application component into a domain to be able to unload the domain (and the component) without having to stop the entire application.

AppDomainは、アプリケーション ドメインに対するプログラム インターフェイスです。The AppDomain is the programmatic interface to application domains. このクラスには、ドメインを作成およびアンロードするメソッド、型のインスタンスをドメイン内に作成するメソッド、およびアプリケーション ドメインのアンロードなどの各種通知に登録するメソッドが含まれています。This class includes methods to create and unload domains, to create instances of types in domains, and to register for various notifications such as application domain unloading. 一般的に使用される AppDomain メソッドを次の表に示します。The following table lists commonly used AppDomain methods.

AppDomain メソッドAppDomain Method 説明Description
CreateDomain 新しいアプリケーション ドメインを作成します。Creates a new application domain. AppDomainSetup オブジェクトを指定するこのメソッドのオーバーロードを使用することをお勧めします。It is recommended that you use an overload of this method that specifies an AppDomainSetup object. これは、アプリケーション ベース (アプリケーションのルート ディレクトリ)、ドメインの構成ファイルの場所、ドメインにアセンブリを読み込むときに共通言語ランタイムが使用する検索パスなど、新しいドメインのプロパティを設定する場合に望ましい方法です。This is the preferred way to set the properties of a new domain, such as the application base, or root directory for the application; the location of the configuration file for the domain; and the search path that the common language runtime is to use to load assemblies into the domain.
ExecuteAssembly および ExecuteAssemblyByNameExecuteAssembly and ExecuteAssemblyByName アプリケーション ドメインでアセンブリを実行します。Executes an assembly in the application domain. これはインスタンス メソッドであるため、参照先の別のアプリケーション ドメインでコードを実行する場合に使用できます。This is an instance method, so it can be used to execute code in another application domain to which you have a reference.
CreateInstanceAndUnwrap 指定した型のインスタンスをアプリケーション ドメイン内に作成し、プロキシを返します。Creates an instance of a specified type in the application domain, and returns a proxy. このメソッドを使用することで、作成された型を含むアセンブリが呼び出し元のアセンブリに読み込まれることを回避できます。Use this method to avoid loading the assembly containing the created type into the calling assembly.
Unload ドメインを正常にシャットダウンします。Performs a graceful shutdown of the domain. アプリケーション ドメインは、ドメイン内で実行されているすべてのスレッドが停止するか、またはドメイン内に存在しなくなるまで、アンロードされません。The application domain is not unloaded until all threads running in the domain have either stopped or are no longer in the domain.

注意

共通言語ランタイムはグローバル メソッドのシリアル化をサポートしないため、デリゲートを使用して他のアプリケーション ドメインでグローバル メソッドを実行できません。The common language runtime does not support serialization of global methods, so delegates cannot be used to execute global methods in other application domains.

共通言語ランタイムの仕様、「Hosting Interfaces」で説明されているアンマネージ インターフェイスも、アプリケーション ドメインへのアクセスを提供します。The unmanaged interfaces described in the common language runtime Hosting Interfaces Specification also provide access to application domains. ランタイム ホストは、アンマネージ コードのインターフェイスを使用して、プロセス内にアプリケーション ドメインを作成し、そのドメインにアクセスできます。Runtime hosts can use interfaces from unmanaged code to create and gain access to the application domains within a process.

COMPLUS_LoaderOptimization 環境変数COMPLUS_LoaderOptimization Environment Variable

実行可能アプリケーションの既定のローダーの最適化ポリシーを設定する環境変数。An environment variable that sets the default loader optimization policy of an executable application.

構文Syntax

COMPLUS_LoaderOptimization = 1  

コメントRemarks

一般的なアプリケーションでは、アプリケーション ドメインに複数のアセンブリが読み込まれてから、それに含まれるコードが実行されます。A typical application loads several assemblies into an application domain before the code they contain can be executed.

アセンブリが読み込まれる方法によって、そのアセンブリの Just-In-Time (JIT) コンパイル コードをプロセス内の複数のアプリケーション ドメインで共有できるかどうかが決まります。The way the assembly is loaded determines whether its just-in-time (JIT) compiled code can be shared by multiple application domains in the process.

  • アセンブリがドメイン中立として読み込まれる場合は、同じセキュリティ許可セットを共有するすべてのアプリケーション ドメインが同じ JIT コンパイル コードを共有できます。If an assembly is loaded domain-neutral, all application domains that share the same security grant set can share the same JIT-compiled code. このため、アプリケーションが必要とするメモリを抑えることができます。This reduces the memory required by the application.

  • アセンブリがドメイン中立として読み込まれない場合、読み込まれるすべてのアプリケーション ドメインで JIT コンパイル済みである必要があり、またローダーはアプリケーション ドメイン間で内部リソースを共有できません。If an assembly is not loaded domain-neutral, it must be JIT-compiled in every application domain in which it is loaded and the loader must not share internal resources across application domains.

COMPLUS_LoaderOptimization 環境フラグを 1 に設定すると、ランタイム ホストは強制的にすべてのアセンブリを SingleDomain と呼ばれるドメイン中立でない方法で読み込みます。When set to 1, the COMPLUS_LoaderOptimization environment flag forces the runtime host to load all assemblies in non-domain-neutral way known as SingleDomain. SingleDomain では、常にドメインに中立として読み込まれる Mscorlib を除き、どのアセンブリもドメインに中立として読み込まれません。SingleDomain loads no assemblies as domain-neutral, except Mscorlib, which is always loaded domain-neutral. この設定は、ホストがプロセス内で 1 つのアプリケーションだけを実行する場合に一般的に使用されるため、シングル ドメインと呼ばれます。This setting is called single domain because it is commonly used when the host is running only a single application in the process.

注意事項

COMPLUS_LoaderOptimization 環境フラグは診断およびテストのシナリオで使用するように設計されています。The COMPLUS_LoaderOptimization environment flag was designed to be used in diagnostic and test scenarios. このフラグをオンにすることにより、速度の大幅な低下と使用メモリの増大が発生する場合があります。Having the flag turned on can cause severe slow-down and increase in memory usage.

コード例Code Example

環境の HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\IISADMIN キーの複数文字列値に COMPLUS_LoaderOptimization=1 を追加することにより、強制的にすべてのアセンブリを IISADMIN サービスにドメイン中立として読み込まないようにできます。To force all assemblies not to be loaded as domain-neutral for the IISADMIN service can be achieved by appending COMPLUS_LoaderOptimization=1 to the Environment’s Multi-String Value in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\IISADMIN key.

Key = HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\IISADMIN  
Name = Environment  
Type = REG_MULTI_SZ  
Value (to append) = COMPLUS_LoaderOptimization=1  

参照Reference

System.MarshalByRefObject