问题标签 [activation-context-api]

我目前正在尝试使用免注册 COM 运行一个相当复杂的方案。

并不是说它不起作用，而是我遇到了一种令人困惑的情况，似乎我应该直接在应用程序上下文中激活程序集依赖项的清单，而不是让应用程序上下文指向依赖程序集。

由MS 自己发布的示例项目很容易解释：

通常，您有一个应用程序、一个应用程序清单、一个（服务器）dll 及其程序集清单。这些对应于示例给出的内容：

• 客户端程序
• client.exe.manifest（这个指向SideBySide.X as dependentAssembly）
• SideBySide.dll
• SideBySide.X.manifest

现在，一种标准情况是将客户端应用程序清单嵌入客户端可执行文件中，然后使用 DLL 及其外部清单文件。

现在，如果由于某种原因在编译时不知道正确的应用程序清单，您可以在运行时通过Activation Context API加载清单文件。

这就是令人困惑的地方：

根据文章，客户端应用程序现在直接将其激活上下文切换到程序集清单：

如果您查看 client.cpp 中的 _tmain 函数 ... 一段新的代码，用于初始化激活上下文，如下所示：

我已经对此进行了交叉检查，它也可以动态加载包含来自的信息的文件client.exe.manifest，即仅对 SideBySide.X 的引用，并继续使用此激活上下文 - 这也对应于我们嵌入时使用的 ActCtx将正确的应用程序清单放入可执行文件中。

也就是说，actCtx.lpSource = "client.exe.manifest";也可以。

TL；DR直接激活“包含”应用程序代码内的程序集清单的激活上下文（如果有的话）意味着什么。

从文件加载清单时应该这样做吗？（如果是这样，为什么我们不能直接将程序集清单嵌入到可执行文件中，因为它在编译时是已知的。）

注意：（这确实应该是对@Eric Brown 答案的评论，但它变得相当冗长）

链接的文章很好地解释了这两种RT_MANIFEST资源类型，但关于 regFreeCOM，它留下了一些松散的结尾。我会引用一些让我大吃一惊的引语：

ISOLATIONAWARE_MANIFEST_RESOURCE_ID 主要用于 DLL。如果 dll 需要私有依赖项而不是进程默认值，则应该使用它。... NT 库加载器检查 dll 是否具有 RT_MANIFEST 类型的资源，ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID。如果是，加载程序使用资源调用 CreateActCtx，并使用生成的激活上下文来探测dll 的静态依赖项。

我理解这意味着唯一的一点RT_MANIFEST/2是静态DLL 依赖加载器找到用于解决DLL 依赖的正确资源。（不是COM 依赖项，见下文。）

有时，您希望在探测 dll 的静态依赖项之外使用激活上下文。您可以在编译模块时定义宏 ISOLATION_AWARE_ENABLED。

定义 ISOLATION_AWARE_ENABLED 后，Windows 会重新定义某些 API。例如 LoadLibraryExW 被重新定义为 IsolationAwareLoadLibraryExW。

... 并非所有受激活上下文影响的 API 都被包装。例如，...，任何 COM API 都不是。

所以，总结一下：我认为 RT_MANIFEST 机制主要与 regFreeCOM 正交，因为 COM 根本不关心它的激活上下文来自哪里，并且 regFreeCOM wrt 没有内置帮助。隔离意识。

我在我的应用程序中创建了一个 AppDomain。下面是我使用的代码

但ActivationContext在null上面的片段中。谁可以帮我这个事。提前致谢。

我尝试将我的 VS 2012 .Net 项目与使用 VS 2005 构建的旧本机 Dll 放在一个目录中。出于安装原因，我无法在用户机器上安装 VC Redist，因此我将 msvcr、msvcp、msvcm 和 vcomp Dll 放在我从 MS 中找到的最新 redist 版本中，也在该目录中。我已经创建了具有此内容的 .Manifest 文件 Microsoft.VC80.CRT.Manifest 和 Microsoft.VC80.OpenMP.Manifest 文件，例如 CRT：

通过分析事件日志和 sxstrace，我看到他正在寻找版本 8.0.50608.0，我提供并重定向到 8.0.50727.6195。

正如我所说，在 eventvwr 和 sxstrace 中，我看到了一些故障并修复了它们。现在在 eventlog 中什么都没有出现，但 sxstrace 只说：创建激活上下文失败。没有任何理由。从应用程序本身，我得到并排配置错误消息框。

整个东西都是64位的。.Net 应用程序、包装器和本机 Dll。

如果我安装 redist 包，它工作正常。但对于我的目标机器，这是不可能的。

有人有想法吗？

我没有 C++ 和 Win API 方面的经验，如果这个问题是 nooby，我很抱歉。例如，我有 DLL 在其中创建一些组件MessageBox。我添加了编译指示注释以启用视觉样式，但它不起作用（我不应该从这个答案中知道：windows 7 style for combobox on internet explorer工具栏，怎么样？

dll代码（省略导出等）：

然后我从我的应用程序中调用这个 dll 函数：

我有我的消息框，但没有视觉样式。据我了解，我应该在调用我的 dll 时激活上下文，但 MSDN 没有如何执行此操作的示例。您能否给我这样的例子，或者至少更详细地解释发生了什么？因为我什至无法理解为什么函数BOOL GetCurrentActCtx(_Out_ HANDLE *lphActCtx);接收指针ACTCTX但具有某种HANDLE类型的签名。

我目前正在开发一个混合的本地/托管应用程序链，它采用免注册 COM。下图说明了这一点：

C# 包装 DLL 已使用 tlbimp.exe 实用程序创建。这允许每个 C# 可执行文件访问 COM DLL 中的本机类型和方法。COM DLL 本身使用基于服务器的 RegFree COM 清单。

当基于客户端的 RegFree COM 清单嵌入到 C# 可执行文件中时，一切正常。但是，我想将这些清单文件移动并统一到 C# DLL 中，这将显着简化版本信息的维护和同步。

因为 Visual Studio 不提供将清单文件嵌入 C# 类库的选项，所以我尝试使用清单工具 (mt.exe) 提取、修改和重新嵌入 DLL 的默认清单。这似乎奏效了，因为 C# DLL 现在在使用 mt 查询时会公开以下清单：

然而，可执行文件拒绝工作，每个人都抱怨 COM 类工厂无法找到丢失的 COM 模块。

有什么我在这里忽略的吗？谢谢。

我目前正在处理混合托管/本地工作链，需要为免注册 COM 支持创建激活上下文（请参阅将免注册 COM 清单嵌入到具有本地/托管环境的 C# dll 中）。以下代码片段是 C# DLL 中较大类的一部分，该类包含对 COM Wrapper 的引用并建立所需的激活上下文：

问题在于方法DeactivateActCtx()内部的 pinvoked 函数DestroyActivationContext()。一旦调用，SEHException就会抛出一个：外部组件抛出了异常。0x80004005。

该Marshal.GetLastWin32Error()函数没有可用的错误代码，这将为我提供一些合理的信息。

到目前为止我尝试过的事情：

• 将DestroyActivationContext()函数从析构函数移动到Dispose方法，反之亦然。
• 完全删除IDisposable接口。
• 将底层 COM 对象的线程模型从 Apartment 更改为 Free。
• 提供DeactivateActCtx()函数DEACTIVATE_ACTCTX_FLAG_FORCE_EARLY_DEACTIVATION作为输入参数。
• IntPtr将实例的类型更改为UIntPtr.

不幸的是，这些选项都没有帮助。是否有任何可能的方法可以在不遇到上述情况的情况下取消激活上下文SEHException？

更新

似乎垃圾收集器的线程是问题的原因。GC 始终在其自己的不同线程中运行，没有明显的可能性来指定其他方式。DeactivateActCtx当试图从该特定线程停用激活上下文 () 时，似乎存在某种访问冲突。所以我想没有直接的方法来处理这种麻烦，除了在每个包装的调用中激活和停用激活上下文。任何可以证明并非如此的建议仍然受到欢迎。

我需要找出根本原因

EXCEPTION_CODE：（NTSTATUS）0xc015000f - 被停用的激活上下文不是最近激活的。

使用用户模式事后崩溃转储。

调用栈：

我很确定这0x1fb2adc6是ulCookie传递给DeleteActCtx调用的值（即DeactivateActCtx( 0, 0x1fb2adc6 )），但我不知道下一步该去哪里确定它为什么在上下文之外被停用。

我不能用特殊的异常设置重新运行程序；我们从客户安装收到的这个用户模式故障转储就是我必须使用的全部内容。

的输出!PEB显示了有关环境的以下内容：

我正在尝试使用CreateActCtxWin32 API。互联网上使用此功能的代码并不多，但经过大量谷歌搜索后，我找到了两个讨论这个问题的博客，并走到了这一步。但是，我在 Google 或 SO 上的其他任何地方都没有找到有关此 API 及其调用形式 .Net 的更多信息，这很奇怪。我认为这很奇怪的原因是因为我正在尝试做一些虽然罕见但在我看来是合理的事情。我正在尝试使用免注册的 COM 互操作，其中 COM Dll 驻留在要在运行时确定的文件夹中。当 Dll 位于同一文件夹中时，可以使用清单文件来完成。但是，当 COM Dll 位于执行程序集工作目录之外的另一个文件夹中时，必须向操作系统显式提供清单文件。为什么必须在运行时确定文件夹是目前无法更改的业务需求。我们需要尽快解决这个问题。

我不是 Pinvoke 方面的专家，我真的不知道应该如何调试您从 API 收到的错误消息。在这个特定的情况下，我收到一个错误 87，即“无效参数”，如此处所述。我已尝试阅读有关 Pinvoke 的更多信息，并确保我使用正确的托管类型进行编组，并按照 MSDN 文档中的描述正确使用参数。在这一点上，我真的不知道如何进一步调试！我完全不知道为什么这个方法会返回一条错误消息。这是我的代码（为简洁起见，我删除了激活、释放和其他相关方法）：

有两种模式可以使用此 API。一种是使用嵌入在 EXE 中的清单或使用单独存在的清单文件。目前这两种方法都返回错误消息。我已经测试了清单文件的格式，并且当我不通过 API 时它可以工作（因此清单文件是正确的）。

任何有关如何进一步调试的帮助将不胜感激。

我正在通过 JNI 将基于 COM/CLI 的库集成到基于 Java 的应用程序中（是的，这有点乱）。在大多数情况下它都在工作，但是当谈到激活上下文如何与单线程 COM 对象交互时，我遇到了一些障碍。我的情况可以用下面的代码片段来概括。

库和应用程序的部署迫使我使用免注册 COM。此外，由于主应用程序是用 Java 编写的，因此我无法真正将清单资源附加到 exe 文件或类似文件中。因此，我需要使用 COM 中的激活上下文机制来允许库查找其 COM 类。此外，库本身是单线程的，因此需要 STA 才能运行。但是，我的应用程序将从各种线程调用库。

据我了解，如果要创建的对象是单线程的，那么第一次从 MTA 线程调用 CoCreateInstance 时，COM 将启动一个新的“默认 STA 线程”。然后在默认 STA 中创建实际对象，然后 CoCreateInstance 的返回值将是一个代理对象，它将方法调用来回编组到默认 STA。这一切都很好，这就是我希望它的工作方式。

当我的代码不是第一个导致默认 STA 线程启动的代码时，就会出现我的问题。似乎即使对象创建被封送到默认 STA，当前激活上下文也不是。默认 STA 卡在创建时处于活动状态的激活上下文中。这对我来说意味着如果我不是第一个导致默认 STA 被初始化的人，我对 CoCreateInstance 的调用将失败，因为默认 STA 不知道我的激活上下文。这是一个大型企业应用程序，我不能确定我的代码会第一个调用 CoCreateInstance，即使我可以，这对我来说似乎也是一个脆弱的解决方案。

因此，我需要以下之一：

1. 一种将激活上下文编组到默认 STA 的方法。

2. 一种使用正确激活上下文启动新 STA 的方法，我的对象将在其中存在，并且 CoCreateInstance 和方法调用被来回编组到此 STA 而不是默认 STA。

3. 重构我的集成以确保对有问题的库的所有调用都来自我可以控制的单个 STA，以避免编组步骤。这是我的备用计划，但我觉得必须有更简单的方法。

有什么方法可以查看正在运行的 Windows 进程的激活上下文？

理想情况下，当我说“查看”时，我的意思是以人类可读的方式检查它，例如查看/确认已加载哪些 DLL 等。

我的想象是某种调试器可能会附加到正在运行的进程，然后显示该信息。但任何类型的工具都可能有用 - 调试器、日志文件，甚至使用激活上下文 API 来检查事物等。