问题标签 [appdomain]

我想知道是否有一种方法可以通过编程方式或使用第三方工具（分析器？）来概述 AppDomain 中当前有多少类实例处于活动状态（包括或不包括派生类），甚至更好的是，它们在哪里已分配（不确定这是否可能）。

我知道我可以更改我自己的类以以某种方式包含一些运行计数器，但我也希望将它用于我无法控制的（托管）类。

这甚至可能吗？一些提示或关键字会有所帮助:)

我知道请求由不同的线程提供服务，但它们是否也都来自同一个应用程序域？

我正在编写一个工具来报告有关在我的客户系统中跨环境和区域部署的 .NET 应用程序的信息。

我想读取这些程序集中的程序集属性值。

这可以使用 来实现Assembly.ReflectionOnlyLoad，但是即使这种方法也会使程序集保持加载。这里的问题是我不能从不同的路径加载两个同名的程序集，所以自然不能比较部署在不同系统中的同一个应用程序。

在这一点上，我假设解决方案将涉及使用临时AppDomains。

有人可以详细说明如何将一个程序集加载到另一个程序集中AppDomain，从中读取属性然后卸载AppDomain吗？

这需要适用于文件系统上的程序集以及 URL 地址上的程序集。

I'm currently writing a server that hosts several modules. The server runs each module in a separate AppDomain. What I want to achieve is exception isolation, i.e. when one module throws an exception I don't want whole process to terminate, just this specific AppDomain. I know that I can tell CLR to fallback to old behaviour (.NET 1.0) when all uncaught exceptions in different threads were swallowed. However, this is not the most 'elegant' solution.

这个问题是关于应用程序域和会话的。是否可以让 IIS 在单独的应用程序域中运行每个用户会话。如果是，请让我在配置文件中设置影响这一点的设置。

问候，阿尼尔。

根据我所有的阅读，应该有一个 GC 线程来调用所有终结器。现在，问题是这个“一个”线程的范围是什么——每个进程或每个应用程序域，因为域的全部意图是在一个进程空间中分离并制作“独立”的不同应用程序。

我在这里读到：

如果在终结器中发生未处理的异常，CLR 的执行线程将吞下该异常，将终结器视为正常完成，将其从易碎队列中删除并移至下一个条目。

更严重的是，如果你的终结器由于某种原因没有退出会发生什么，例如它阻塞，等待一个永远不会发生的条件。在这种情况下，终结器线程将被挂起，因此不再有可终结的对象被垃圾收集。您应该非常了解这种情况，并坚持编写最简单的代码来释放终结器中的非托管资源。

另一个考虑因素是应用程序关闭期间会发生什么。当程序关闭时，垃圾收集器将努力调用所有可终结对象的终结器，但有一定的限制：

• 在关闭期间，可终结对象不会提升到更高的堆代。

• 任何单独的终结器将有最多 2 秒的时间来执行；如果需要更长的时间，它将被杀死。

• 所有终结器的执行时间最长为 40 秒；如果此时任何终结器仍在执行或未决，则整个过程会突然终止。

太多帖子（甚至官方文档）滥用术语“应用程序”、“进程”和“应用程序域”——其中大多数甚至假设它们是相等的，因为通常应用程序在单个进程中的单个应用程序域中运行. 这种滥用使所有这些文档都难以阅读，甚至没有用处。

因此，我的问题假设有多个应用程序，每个应用程序都在单个进程的单独应用程序域中运行。

所有这些应用程序是否共享相同的 GC 和终结器线程？上面文章中描述的问题（挂起终结器线程）会影响该进程中的所有应用程序吗？如果是 - 是否有解决方法（除了不使用不良应用程序），例如以某种方式发现终结器线程并将其发送 Thread.Abort？

以上都是因为我遇到了类似的问题。我的应用程序作为第三方软件 (Outlook) 的插件在单独的应用程序域中运行。由于各种原因，我需要调用 GC.Collect 和 GC.WaitForPendingFinalizers 来完全释放 COM 引用（通常的互操作例程对于 Office/Outlook 来说是不够的），当某个特定的其他第三方插件运行时，我的 GC.WaitForPendingFinalizers 永远挂起，所以我怀疑第三方添加中有一个“坏”的终结器。我无法控制替换/删除添加（客户的要求），所以我必须自己弄清楚如何使它们共存。

这是核心问题：我有一个在单独的 AppDomain中使用COM 互操作的 .NET 应用程序。COM 东西似乎正在将程序集加载回默认域，而不是从中调用 COM 东西的 AppDomain。

我想知道的是：这是预期的行为，还是我做错了什么导致这些与 COM 相关的程序集被加载到错误的 AppDomain 中？请参阅下面对情况的更详细描述...

该应用程序由 3 个程序集组成： - 主 EXE，应用程序的入口点。- common.dll，只包含一个接口 IController（IPlugin 样式） - controller.dll，包含一个实现 IController 和 MarshalByRefObject 的 Controller 类。此类完成所有工作并使用 COM 互操作与另一个应用程序进行交互。

主 EXE 的相关部分如下所示：

common.dll 仅包含以下两件事：

并且 controller.dll 包含这个类（它也调用 COM 互操作的东西）：

首次运行应用程序时，Assembly.GetAssemblies() 看起来与预期一样，common.dll 加载到两个 AppDomains 中，而 controller.dll 仅加载到控制器域中。但是，在调用 c.Run() 之后，我看到与 COM 互操作相关的程序集已加载到默认的 AppDomain 中，而不是在发生 COM 互操作的 AppDomain 中。

为什么会发生这种情况？

如果你有兴趣，这里有一点背景：

最初这是一个 1 AppDomain 应用程序。它与之交互的 COM 东西是一个服务器 API，长期使用并不稳定。当 COM 发生 COMException（没有关于其原因的有用诊断信息）时，必须重新启动整个应用程序，然后 COM 连接才能再次工作。简单地重新连接到 COM 应用程序服务器会再次立即导致 COM 异常。为了解决这个问题，我尝试将 COM 互操作的东西移动到一个单独的 AppDomain 中，这样当神秘的 COMExceptions 发生时，我可以卸载它发生的 AppDomain，创建一个新的并重新开始，而无需手动重新启动应用程序. 反正就是这个理论...

在 .Net Activator.GetObject(Type type, string url, object data) 中返回对象的代理。我猜这个代理继承自 MarshalByRefObject 并且可以跨 AppDomains 发送。我对吗？

在我的应用程序中，我在 appdomain A 中创建一个对象并使用它 appdomain B。该对象的成员是使用 Activator.GetObject () 创建的代理对象。因此，当我在 AppDomain B 中时，我对在 appdomain A 中创建的对象有一个透明代理。当我尝试对代理对象执行调用该方法时，我遇到了错误。

例如，我在 App Domain B 中创建了一个 Connection 对象。我在 App Domain A 中有 Connection 对象的透明代理。当我尝试从 AppDomain A 进行这样的调用时遇到错误。 ConnectionObject.SecurityProxy.GetSecurityAccount ( )。看起来问题是当我尝试像上面那样拨打电话时，它试图在 AppDomain A 中再次创建 SecurityProxy，而不是将呼叫转发到 AppDomain B。连接时已经在 AppDomain B 中创建了安全代理对象被创建。

你能帮我弄清楚我做错了什么吗？

问候，阿尼尔。

我被一个架构不佳的解决方案所困扰。它不是线程安全的！

我在解决方案中有几个共享的类和成员，在开发过程中一切都很酷......
BizTalk 击沉了我的战舰。

我们正在使用自定义 BizTalk 适配器来调用我的程序集。适配器正在调用我的代码并并行运行，所以我假设它在同一个 AppDomain 下使用多个线程。

我想做的是让我的代码在它自己的 AppDomain 下运行，这样我遇到的共享问题就不会相互混淆。

我有一个非常简单的类，BizTalk 适配器正在实例化然后运行 ​​Process() 方法。

我想在我的 Process() 方法中创建一个新的 AppDomain，因此每次 BizTalk 旋转另一个线程时，它都会有自己的静态类和方法版本。

BizTalkAdapter 代码：

这是 BizTalk 调用类：

仅供参考：Loader 类与 dataFile 类位于单独的 DLL 中。

任何帮助，将不胜感激。我将继续致力于使代码线程安全，但我觉得这可能是“简单”的答案。

如果有人有其他想法，请提出。

谢谢你，
基思

只是为了完整性。

我确实发现，如果我在“传输高级选项”对话框中将发送适配器标记为“有序交付”，我就能够避免我遇到的多线程问题。

我认为这是我的问题的另一个可能答案，但不一定是这个问题。

我有一个应用程序需要在多个 AppDomain 之间发送大量消息。我知道我可以使用远程处理来实现这一点，但我也注意到存在跨域委托。有没有人看过这种问题？