winapi - 将程序集 list 直接加载到应用程序上下文中是否正确？

Question

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

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

用example project MS themselves publish来解释是相当容易的。 :

通常，您有一个应用程序、一个应用程序 list 、一个(服务器)dll 及其程序集 list 。这些对应什么the example gives :

• 客户端.exe
• client.exe.manifest(这个 指向作为 dependentAssembly的SideBySide.X)
• SideBySide.dll
• SideBySide.X.manifest

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

现在，如果出于某种原因在编译时无法得知正确的应用程序 list ，您可以在运行时通过 Activation Context API 加载 list 文件。 .

这就是令人困惑的地方:

根据本文，客户端应用程序现在直接将其激活上下文切换到程序集 list :

If you look at the _tmain function in client.cpp ... a new section of code that initializes the activation context as follows:

actCtx.lpSource = "SideBySide.X.manifest";

我对此进行了交叉检查，它还可以动态加载包含来自 client.exe.manifest 的信息的文件，即仅引用 SideBySide.X，然后继续此操作激活上下文 - 当我们将正确的应用程序 list 嵌入到可执行文件中时，它也对应于正在使用的 ActCtx。

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

TL;DR 直接激活应用程序代码中“包含”程序集 list 的激活上下文(如果有)意味着什么.

从文件加载 list 时应该这样做吗？(如果是这样，为什么我们不能在编译时已知的情况下直接将程序集 list 嵌入到可执行文件中.)

<小时/>

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

linked article很好地解释了两种 RT_MANIFEST 资源类型，但对于 regFreeCOm，它留下了一些 Unresolved 问题。我将引用一些令我震惊的引言:

ISOLATIONAWARE_MANIFEST_RESOURCE_ID is used primarily for DLLs. It should be used if the dll wants private dependencies other than the process default. ... the NT library loader checks to see if the dll has a resource of type RT_MANIFEST, ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID. If it does, the loader calls CreateActCtx with the resource, and use the generated activation context to probe the dll's static dependencies.

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

Sometimes, you want to use the activation context outside of probing the dll's static dependencies. You can define macro ISOLATION_AWARE_ENABLED when you compile the module.

When ISOLATION_AWARE_ENABLED is defined, Windows re-defines certain APIs. For example LoadLibraryExW is redefined to IsolationAwareLoadLibraryExW.

... Not all APIs affected by activation context are wrapped. For example, ..., and neither is any of the COM APIs.

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

Answer 1

是的，这就是应该如何完成的，并且您可以将程序集 list 嵌入到可执行文件中(即资源部分)。这就是 RT_MANIFEST资源类型用于。有two default types of manifest resources

• 流程 list ，包含 ID CREATEPROCESS_MANIFEST_RESOURCE_ID (1)，在流程创建期间使用，
• 隔离感知 list ，包含 ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID (2)、DLL加载时使用。

有几个用途(主要围绕单击一次部署)说明了使用 RT_MANIFEST 在附属 DLL 中嵌入免注册 COM list 的能力。特别是，如果 DLL 具有 CREATEPROCESS_MANIFEST_RESOURCE_ID，则也将使用该 list 。

这里有一个例子似乎是一件好事。

给定

• 客户端.exe
• sidebyside.dll

如果 sidebyside.dll 具有 ID 为 1 (CREATEPROCESS_MANIFEST_RESOURCE_ID) 的 RT_MANIFEST 资源，其中包含相应的免注册 COM 条目，并且 client.exe 具有 ID 为 1 且具有 <file> 的 RT_MANIFEST 资源。入口为sidebyside.dll，那么Win32将自动处理免注册COM管理。

Part 8 of the example article强烈暗示了这一点，而且我已经在许多内部项目中看到了这一点。