Application和AppDomain.CurrentDomain之间有什么区别

Question

我对Application类和AppDomain类的使用感到困惑。
例如， Application.StartupPath等于AppDomain.CurrentDomain.BaseDirectory

我通常使用Application类并且最近发现了AppDomain - 有人可以向我解释AppDomain类及其用法吗？

Answer 1

他们没有任何共同点，真的。

Application是特定于Windows Forms（.NET GUI技术）的类。 Application.StartupPath由Kernel32函数GetModuleFileName处理。 通过不传递指向模块的指针，返回主模块的路径 - 基本上就是exe文件。

AppDomain是域隔离的核心.NET概念。 基本上，它允许您在单个本机进程中隔离（当然不完美）多个应用程序。 大多数应用程序只有一个AppDomain ，但您可以根据需要创建任意数量的AppDomain 。 应用程序域的基本路径由Fusion（一种.NET程序集加载技术）处理。 一个非常典型的例子是IIS中托管的ASP.NET应用程序 - 每个应用程序都有自己的AppDomain ，但它们都托管在一个本机进程（“应用程序池”）中。 每个逻辑应用程序都可以在不触及其他逻辑应用程序的情况下重新启动，并且它们之间没有（简单）访问权限，但是流程撕裂异常（例如StackOverflowException ）仍将终止整个池。

另一个有趣的课程是Environment 。 您可以使用Environment.CommandLine来获取进程命令行（包括可执行文件的路径，包括可执行文件的名称）。 这基本上是CLR和底层系统之间的通信接口 - 在这种情况下，它负责保存应用程序的参数（由OS传递给Main函数）并在将来的任何时候使它们可用。

Environment.CommandLine有点笨拙解析（它是原始命令行，基本上 - 我认为它在Windows上会有不同于Linux上的约定），但它是你总能找到可执行文件的唯一方法。 同样， Application.StartupPath是特定于Winforms的，并且您可以拥有多个AppDomain - 可能， AppDomain可能甚至没有合理的BaseDirectory 。

.NET Reflection API还为您提供了几种方法。 例如， Assembly.GetEntryAssembly()将为您提供可执行程序集 - 但是，这仅适用于主AppDomain - 其他域将具有自己的条目程序集（实际上，它们通常只返回null :)）。 您可以通过Assembly.CodeBase属性获取程序集的路径，但请注意，这可能并不总是您所期望的。 您还可以使用Assembly.Location ，或获取任何程序集模块的FullyQualifiedName （同样，大多数程序集只有一个模块;而且，ASP.NET不是这种情况的主要示例之一） 。