blocks|key|2656107|text|使用应用程序域的一些实际好处：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2656108|2656109|可以在一个进程中运行多个应用程序域。您还可以停止单个应用程序域，而无需停止整个过程。仅此一项就极大地提高了服务器的可伸缩性。|unordered-list-item|2656110|管理应用程序域生命周期由运行时主机以编程方式完成(您也可以覆盖它)。对于进程和线程，必须显式地管理它们的生命周期。初始化、执行、终止、进程间/多线程通信都很复杂，这就是为什么将其交给CLR管理更容易的原因。|2656111|2656112|来源：https://docs.microsoft.com/en-us/dotnet/framework/app-domains/application-domains|offset|length|2656113|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.microsoft.com/en-us/dotnet/framework/app-domains/application-domains^0|0|0|0|0|0|3|29|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|X|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Z|8|@]|9|@$K|10|L|11|1|12]]|A|$]]|$1|M|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

Some practical benefits using app domain:

<ul>
<li>Multiple app domains can be run in a process. You can also stop individual app domain without stopping the entire process. This alone drastically increases the server scalability. </li>
<li>Managing app domain life cycle is done programmatically by runtime hosts (you can override it as well). For processes &amp; threads, you have to explicitly manage their life cycle. Initialization, execution, termination, inter-process/multithread communication is complex and that's why it's easier to defer that to CLR management. </li>
</ul>

Source: <a href="https://docs.microsoft.com/en-us/dotnet/framework/app-domains/application-domains" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/dotnet/framework/app-domains/application-domains</a>

blocks|key|7498|text|我不知道你是在泛指.NET的AppDomain，还是具体说.NET的.NET。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|7499|我将假设.NET的AppDomain，以及为什么当您需要在单个进程中进行隔离时，它会非常有用。|7500|以为例：|BOLD|7501|假设您正在处理一个包含某些worker类的库，您别无选择，只能使用这些worker，并且不能修改代码。您的工作是构建一个Windows服务来管理上述工作程序，并确保它们都保持正常运行，并且需要并行工作。|7502|很简单，对吧？好吧，你希望如此。事实证明，您的worker库很容易抛出异常，使用static配置，并且通常只是一个真正的PITA。|7503|您可以尝试在它们自己的进程中启动它们，但要监视它们，您需要实现命名管道，或者尝试仔细地解析进程的STDIN和STDOUT。|7504|你还能做什么？嗯，AppDomain实际上解决了这个问题。我可以为每个worker生成一个AppDomain，为它们提供自己的配置，它们不会因为更改static属性而搞砸彼此，因为它们是独立的，最重要的是，如果库崩溃，而我未能捕捉到异常，它不会干扰它们域中的worker。在所有这些过程中，我仍然可以很容易地与这些员工进行交流。|7505|可悲的是，我以前也这样做过。|7506|编辑:开始将此作为注释响应写入，但变得太大|7507|单独的流程在许多情况下都可以很好地工作，然而，有时它们可能会成为一种痛苦。我并不是说一个人应该在另一个进程上使用AppDomain。我认为你需要一个单独的进程或AppDomain是不常见的，但是一旦你需要它，你肯定会知道的。|7508|我在上面给出的场景中看到的进程的主要问题是，进程有自己的缺陷，使用AppDomain可以更容易地缓解这些缺陷。|7509|进程可能在任何时候变得无赖、变得无响应、崩溃或被终止。|7510|如果您正在管理进程，则需要跟踪进程ID并监视其状态。IPC很棒，但如果需要的话，需要时间来进行适当的通信。|7511|举个例子，假设你的进程就这么死了。你的工作是什么?根据您选择监视的机制，可能是通信线程死了，也可能是工作完成了，而您仍然将其显示为“正在处理”。你的工作是什么?|7512|现在，当您有20个进程，而您的管理应用程序停止运行时，会发生什么情况。你没有任何真实的信息，你只有20个"myprocess.exe“，也许现在必须开始解析命令行参数，看看你实际有哪些工人。显然，有了AppDomain，所有20个都会死掉，但你真的从这个过程中获得了什么吗？然而，您仍然需要编写恢复能力的代码，但是，现在您还必须为您的进程编写所有恢复代码，而不仅仅是解雇工作人员备份。|7513|正如编程中的任何事情一样，有1000种不同的方法可以实现相同的目标。由您决定您认为哪种解决方案最合适。|7514|entityMap^0|E|9|0|9|9|0|1|3|0|0|14|6|0|0|9|9|22|6|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1F|8|@$9|1G|A|1H|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1I|8|@$9|1J|A|1K|B|J]]|D|@]|E|$]]|$1|K|3|L|5|6|7|1L|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|1M|8|@$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|O|3|P|5|6|7|1P|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1Q|8|@$9|1R|A|1S|B|C]|$9|1T|A|1U|B|C]]|D|@]|E|$]]|$1|S|3|T|5|6|7|1V|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|1W|8|@]|D|@]|E|$]]|$1|W|3|X|5|6|7|1X|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1Y|8|@]|D|@]|E|$]]|$1|10|3|11|5|6|7|1Z|8|@]|D|@]|E|$]]|$1|12|3|13|5|6|7|20|8|@]|D|@]|E|$]]|$1|14|3|15|5|6|7|21|8|@]|D|@]|E|$]]|$1|16|3|17|5|6|7|22|8|@]|D|@]|E|$]]|$1|18|3|19|5|6|7|23|8|@]|D|@]|E|$]]|$1|1A|3|-4|5|6|7|24|8|@]|D|@]|E|$]]]|1B|$]]

I can't tell if you are talking in general or specifically .NET's <code>AppDomain</code>. 

I am going to assume .NET's <code>AppDomain</code> and why it can be really useful when you need that isolation inside of a single process. 

For instance: 
Say you are dealing with a library that had certain worker classes and you have no choice, but to use those workers and can't modify the code. It's your job to build a Windows Service that manages said workers and makes sure they all stay up and running and need to work in parallel. 

Easy enough right? Well, you hoped. It turns out your worker library is prone to throwing exceptions, uses a <code>static</code> configuration, and is generally just a real PITA.

You could try to launch them in their own process, but monitor them, you'll need to implement namedpipes or try to thoughtfully parse the STDIN and STDOUT of the process. 

What else can you do? Well <code>AppDomain</code> actually solves this. I can spawn an AppDomain for each worker, give them their own configuration, they can't screw each other up by changing <code>static</code> properties because they are isolated, and on top of that, if the library bombs out and I failed to catch the exception, it doesn't bother the workers in their domain. And during all of this, I can still communicate with those workers easily.

Sadly, I have had to do this before

EDIT: Started to write this as a comment response, but got too large

Individual processes can work great in many scenarios, however, there are just times where they can become a pain. I am not saying one should use an AppDomain over another process. I think it's uncommon you would need a separate process or AppDomain, but once you need it, you'll definitely know.

The main problem I see with processes in the scenario I've given above is that processes have their own downfalls that are easier to mitigate with the AppDomain. 

A process can go rogue, become unresponsive, and crash or be killed at any point. 

If you're managing processes, you need to keep track of the process ID and monitor the status of it. IPCs are great, but it does take time to get proper communication going back and forth as needed. 

As an example let's say your process just dies. What do you do? Depending on the mechanism you chose to monitor, maybe the communication thread died, perhaps the work finished and you still show it as "processing". What do you do? 

Now what happens when you have 20 processes and your management app dies. You don't have any real information, all you have is 20 "myprocess.exe" and maybe now have to start parsing the command line arguments they were started with to see which workers you actually have. Obviously with an AppDomain all 20 would have died too, but did you really gain anything with the process? You still have to code the ability to recover, however, now you have to also code all of the recovery for your processes instead of just firing the workers back up. 

As with anything in programming, there's 1,000 different ways to achieve the same goal. It's up to you to decide which solution you feel is most appropriate.

I understand that an application domain forms:

an isolation boundary for security, 
versioning, 
reliability, 
and unloading of managed code, 

but so does a process

<ol>
<li>Can someone please help me understand the practical benefits of an application domain? </li>
<li>I assumed app domain provides you a container to load one version of an assembly but recently I discovered that multiple versions of strong key assembly can be loaded in an app domain. </li>
</ol>

My concept of application domain is still not clear. And I am struggling to understand why this concept was implemented when the concept of process is present. 

Thank you.

C# What exactly is application domain?

服务器

Windows

容器

我知道应用程序域的形式是：用于托管代码的安全性、版本控制、可靠性和卸载的隔离边界，但是一个过程也是如此有人能帮我理解应用程序域的实际好处吗？我假设应用程序域提供了一个容器来加载一个版本的程序集，但最近我发现一个应用程序域中可以加载多个版本的强密钥程序集。我对应用领域的概念还不是很清楚。我正在努力理解为什么在存在过程概念...

问C#究竟什么是应用程序域？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C#究竟什么是应用程序域？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C#究竟什么是应用程序域？
EN