.net 我不了解应用程序域

I don't understand Application Domains

提问by Jeremy Edwards

.NET has this concept of Application Domains which from what I understand can be used to load an assembly into memory. I've done some research on Application Domains as well as go to my local book store for some additional knowledge on this subject matter but it seems very scarce.

.NET 有应用程序域的这个概念，据我所知，它可用于将程序集加载到内存中。我对 Application Domains 做了一些研究，并去我当地的书店了解了一些关于这个主题的额外知识，但它似乎非常稀缺。

All I know that I can do with Application Domains is to load assemblies in memory and I can unload them when I want.

我只知道我可以使用应用程序域在内存中加载程序集，我可以在需要时卸载它们。

What are the capabilities other that I have mentioned of Application Domains? Do Threads respect Application Domains boundaries? Are there any drawbacks from loading Assemblies in different Application Domains other than the main Application Domains beyond performance of communication?

我提到的应用程序域的其他功能是什么？线程是否尊重应用程序域边界？除了通信性能之外，在除主要应用程序域之外的不同应用程序域中加载程序集是否有任何缺点？

Links to resources that discuss Application Domains would be nice as well. I've already checked out MSDN which doesn't have that much information about them.

链接到讨论应用程序域的资源也会很好。我已经查看了 MSDN，它没有太多关于它们的信息。

回答by JaredPar

AppDomains best visualized as a very light weight process.

AppDomains 最好可视化为一个非常轻量级的过程。

There can be N AppDomains per .Net Process but generally speaking there is only one. The real advantage of AppDomains is they provide an isolation boundary within your process. Objects can only talk to each other across an AppDomain boundary via remoting or serialization.

每个 .Net 进程可以有 N 个 AppDomains，但一般来说只有一个。AppDomains 的真正优势在于它们在您的流程中提供了一个隔离边界。对象只能通过远程处理或序列化跨越 AppDomain 边界相互通信。

It's also possible to run 2 AppDomains at completely different security levels within a process. This can allow you to run your main application at Full Trust while running Untrusted Plugins at a much lower trust level.

还可以在一个进程中以完全不同的安全级别运行 2 个 AppDomain。这可以让您在完全信任的情况下运行主应用程序，同时以低得多的信任级别运行不受信任的插件。

It's hard to blanket say yes or no to whether or not a thread respects an AppDomain. It's possible for a single thread to be in N different AppDomains. Such a situation is possible if an object in one AppDomain makes a remote call to an object in another AppDomain. The thread will have to transition between the AppDomains in order to complete.

一个线程是否尊重 AppDomain 很难一概而论。单个线程可能位于 N 个不同的 AppDomain 中。如果一个 AppDomain 中的对象远程调用另一个 AppDomain 中的对象，则可能出现这种情况。线程必须在 AppDomain 之间转换才能完成。

The disadvantage of AppDomains is mainly complexity. Remoting can take a little bit of time to get your head around and properly setting up an AppDomain can be a non-trivial process.

AppDomains 的缺点主要是复杂。远程处理可能需要一点时间来让您了解，正确设置 AppDomain 可能是一个重要的过程。

You may want to take a peek through the MSDN documentation on AppDomains. It's hard to find a succint tutorial that describes them because they have a variety of complex features. This provides a nice overview which if it doesn't answer your question directly will at least point you in the right place.

您可能需要查看 AppDomains 上的 MSDN 文档。很难找到描述它们的简洁教程，因为它们具有各种复杂的功能。这提供了一个很好的概述，如果它没有直接回答您的问题，至少会为您指明正确的位置。

http://msdn.microsoft.com/en-us/library/cxk374d9.aspx

http://msdn.microsoft.com/en-us/library/cxk374d9.aspx

This document is no longer maintained please refer to this for the updated version: https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

本文档不再维护，更新版本请参考：https: //msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

回答by Cheeso

JaredPar's answer is good, except he doesn't note the raison d'etrefor AppDomains - which is that you can only UNLOAD an Assembly by unloading its AppDomain. If you are a long-running OS process, and you expect to have to load and then later unloadassemblies for whatever reason then you need an AppDomain. The prototypical example here is ASP.NET, which loads app code assemblies on demand and then can unload them later, when the apps are no longer being actively used.

JaredPar 的回答很好，只是他没有注意到AppDomains的存在理由——即您只能通过卸载其 AppDomain 来卸载程序集。如果您是一个长时间运行的操作系统进程，并且您希望无论出于何种原因都必须加载然后卸载程序集，那么您需要一个 AppDomain。这里的典型示例是 ASP.NET，它按需加载应用程序代码程序集，然后可以在以后不再主动使用应用程序时卸载它们。

The cost you pay for the ability to unload is that independence - you need to communicate across the AppDomain boundary, Can't make a simple method call. You need to manage the AppDomain lifecycle. Etc.

你为卸载能力付出的代价就是那种独立性——你需要跨AppDomain边界进行通信，不能进行简单的方法调用。您需要管理 AppDomain 生命周期。等等。

If you just need to dynamically load Assemblies and don't think you'll need to unload them during the life of a single processthen you probably don'tneed to run multiple AppDomains. A good example here might be a rich app that supports a plug-in model, where it sniffs out plug-in assemblies in a "etc" directory and loads 'em all up. However, if the plug-in model calls for unloading the plug-ins ... well.

如果你只是需要动态加载程序集，并且不认为你需要卸载它们单个进程的生命周期中，那么你可能并不需要运行多个应用程序域。这里的一个很好的例子可能是一个支持插件模型的丰富应用程序，它在“etc”目录中嗅探插件程序集并加载它们。但是，如果插件模型要求卸载插件......好吧。

There are outlyer scenarios. Like, suppose you want to load 2 different versions of an Assembly at the same time. You can run into pitfalls if you don't segregate them with AppDomains. But that will be fairly rare.

有异常情况。例如，假设您想同时加载 2 个不同版本的程序集。如果您不使用 AppDomains 将它们隔离，您可能会遇到陷阱。但这将是相当罕见的。

The core scenario that justifies the existence of AppDomains is the long running process that must be able to unload assemblies.

证明 AppDomains 存在的核心方案是必须能够卸载程序集的长时间运行的进程。

Of course, applications could rely on the OS process when you want to unload an assembly. In other words, you could have 3 or 4 cooperating processes running, each with its own set of Assemblies, and when you want to unload an assembly, just shut down the process that hosts that assembly. But the AppDomain offers a higher-perf mechanism to do that, without requiring process stop/start or cross-process comms, which is heavier still than the cross-AppDomain comms described previously. I mean it's still remoting but it is slower and more context switching.

当然，当您要卸载程序集时，应用程序可以依赖于操作系统进程。换句话说，您可以运行 3 或 4 个协作进程，每个进程都有自己的一组程序集，当您想要卸载程序集时，只需关闭承载该程序集的进程即可。但是 AppDomain 提供了一种更高性能的机制来做到这一点，不需要进程停止/启动或跨进程通信，这比之前描述的跨 AppDomain 通信更重。我的意思是它仍然是远程处理，但速度更慢，上下文切换更多。

回答by Jeroen Landheer

Some things you can do with AppDomains:

您可以使用 AppDomains 执行以下操作：

• you can shut it down without endangering the stability of your program.
• You can load code and give this less privileges then your own process (e.g. your process runs fully trusted but you load code in a separate AppDomain that cannot even create a file on the disk.)
• You can handle unhandled exceptions of a AppDomain without having to crash your process.
• Etc.

• 您可以关闭它而不会危及程序的稳定性。
• 您可以加载代码并提供比您自己的进程更少的权限（例如，您的进程运行完全受信任，但您在单独的 AppDomain 中加载代码，该 AppDomain 甚至无法在磁盘上创建文件。）
• 您可以处理 AppDomain 的未处理异常，而不必使您的进程崩溃。
• 等等。

Simply put, it's a security boundary and allmost a process boundary. As far as performance goes, multiple AppDomains within a process does not represent significant overhead. Launching a separate process instead of an AppDomain is far more costly.

简单地说，它是一个安全边界，而且几乎是一个进程边界。就性能而言，一个进程中的多个 AppDomains 并不代表显着的开销。启动单独的进程而不是 AppDomain 的成本要高得多。