我不了解应用程序域
.NET有这个应用程序域的概念，据我所知，可以用来将程序集加载到内存中。 我已经做了一些关于应用程序域的研究，以及去当地的书店了解关于这个主题的其他知识，但是看起来很less。
我所知道的，我可以用Application Domains做的是在内存中加载程序集，我可以在需要的时候卸载它们。
其他我提到的应用程序域的function是什么？ 线程是否尊重应用程序域边界？ 除了主应用程序域之外的其他应用程序域中，除了执行通信之外，还有加载组件的缺点吗？
讨论应用程序域的资源链接也不错。 我已经检查出MSDN，没有那么多关于他们的信息。
AppDomains最好的可视化是一个非常轻的过程。
每个.Net进程可以有N个AppDomain，但一般来说只有一个。 AppDomain的真正优势是它们在您的stream程中提供了隔离边界。 对象只能通过远程处理或序列化跨AppDomain边界彼此通话。
也可以在一个进程中以完全不同的安全级别运行2个AppDomain。 这可以允许您以完全信任的方式运行主应用程序，同时以低得多的信任级别运行不受信任的插件。
对于线程是否尊重AppDomain，很难说是或否。 单个线程可能位于N个不同的AppDomain中。 如果一个AppDomain中的对象对另一个AppDomain中的对象进行远程调用，则可能出现这种情况。 线程将不得不在AppDomain之间进行转换才能完成。
AppDomain的缺点主要是复杂性。 远程处理可能需要一些时间才能让你头脑清醒，正确地设置一个AppDomain可能是一个不平凡的过程。
您可能需要查看AppDomains上的MSDN文档。 很难find描述它们的简单教程，因为它们有各种复杂的function。 这提供了一个很好的概述，如果它不直接回答你的问题将至less指出你在正确的地方。
http://msdn.microsoft.com/en-us/library/cxk374d9.aspx
不再维护此文档请参阅此更新版本： https : //msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx
JaredPar的回答是好的，除非他没有注意到AppDomain的存在 – 这是你只能通过卸载它的AppDomain卸载程序集。 如果你是一个长期运行的OS进程，并且你期望不得不加载，然后以任何理由卸载程序集，那么你需要一个AppDomain。 这里的典型示例是ASP.NET，它根据需要加载应用程序代码程序集，然后可以在应用程序不再被主动使用时卸载它们。
您为卸载能力付出的代价是独立性 – 您需要跨AppDomain边界进行通信，无法进行简单的方法调用。 您需要pipe理AppDomain生命周期。 等等。
如果你只是需要dynamic加载组件，并不认为你需要在一个进程的生命周期中卸载它们，那么你可能不需要运行多个AppDomain。 这里的一个很好的例子可能是一个支持插件模型的丰富的应用程序，它在“etc”目录中嗅探插件，并加载它们。 但是，如果插件模型要求卸载插件…那么。
有更多的情况。 就像，假设你想同时加载2个不同版本的Assembly。 如果您不使用AppDomain隔离它们，可能会陷入陷阱。 但那将是相当罕见的。
certificateAppDomain存在的核心场景是长时间运行的进程，必须能够卸载程序集。
当然，当你想卸载一个程序集时，应用程序可以依靠OS进程。 换句话说，您可以运行3或4个合作进程，每个进程都有自己的一套程序集，当您想卸载程序集时，只需closures承载程序集的进程即可。 但是，AppDomain提供了一个更高性能的机制来实现这一点，而不需要进程停止/启动或跨进程通信，这比前面描述的跨AppDomain通信更重要。 我的意思是它仍然是远程处理，但它是更慢，更多的上下文切换。
一些你可以用AppDomain做的事情：
- 您可以closures它而不危及程序的稳定性。
- 您可以加载代码，然后为自己的进程赋予更less的权限（例如，您的进程运行完全可信，但您将代码加载到单独的AppDomain中，甚至无法在磁盘上创build文件）。
- 你可以处理一个AppDomain的未处理的exception，而不必崩溃你的进程。
- 等等。
简而言之，这是一个安全边界，并且几乎是一个过程边界。 就性能而言，一个进程中的多个AppDomain并不代表相当大的开销。 启动一个单独的进程，而不是一个AppDomain是更昂贵的。
