问题标签 [regfreecom]

这真让我抓狂。我开发了一个 .NET COM DLL，VB6 DLL 包装器使用它来更新和替换应用程序中的一些遗留函数。

我现在正在尝试删除在客户端机器上使用 regasm 的要求，因此我已经研究了如何在测试 DLL 上执行此操作，并且一切正常。

为了以防万一，我分支了 DLL 并添加了一个 app.manifest 文件。其他一切都很好，我得到了一切工作。清单是嵌入的，Visual Studio 2012 在发布文件夹中生成一个 mydll.dll.manifest 文件。

然后我回到原来的主干并添加了一个 app.manifest 文件（合并没有意义，因为没有代码更改）。我将分支的内容复制到 app.manifest 文件中并构建了发布版本。清单嵌入在 DLL 中，但没有生成 mydll.dll.manifest 文件。

我知道拥有 mydll.dll.manifest 文件并不是绝对必要的，但我希望事情保持一致（并且由于某种原因，测试过程不会产生与主干版本相同的结果）所以我该如何强制它要创建吗？

这是一个 VB.NET DLL 项目，因此它没有（或我找不到）此处第一个答案中提到的“生成清单”属性下拉列表。我该如何设置？或者有没有办法通过直接编辑项目文件来设置它？

参考：

• 原始演练文章和一些更正。
• 张俊峰在两篇文章中的概述以及一个有用的工具

我有一个应用程序 A 和一个 DLL B，它们都是在 VS2010 中构建的非托管 C++。DLL B 是一个 COM 服务器。对于某些方法和类，A 使用与 B 的隐式 C++ 链接，但它也通过 COM 访问在 B 中实现的 coclass。这在使用注册 COM 时一切正常，但是当 A 通过免注册 COM 使用 B 时，出现了一个奇怪的问题。

当我从 IDE（F5 或 Ctrl+F5）中启动 A 时，我的应用程序在尝试共同创建在 B 中实现的 coclass 时崩溃。我还注意到，当我尝试调试它时，Visual Studio 调试器有时会忽略我的命令进入方法。源代码和实际执行的代码似乎不同步。

然后我最终找到了问题的原因：在应用程序 A 的调试设置命令中设置为 $(TargetPath)。$(TargetPath) 反过来使用项目的输出目录，该目录设置为“$(ProjectDir)..\bin\”。将输出目录更改为不包含“..”父目录语法的绝对路径，解决了问题，即使指向的目录完全相同。

谁能解释那里发生了什么？我有一个模糊的想法，这与我的应用程序在启动时通过隐式 C++ 链接加载 B.dll 并且还在其清单中将其列为依赖程序集以用于免注册 COM 的事实有关。这会导致 B dll 以某种方式被加载两次吗？为什么只有在从 IDE 中启动 A 时才会发生这种情况？从命令行启动 A 时，在路径中使用“..”可以正常工作。

我们已经使用 RegFree Com 一年多了，现在成功地创建了混合 VB6/VB.Net 程序。由于我们现在想在 Net 4.5 中开发一些组件，我们必须从 Win7 开始使用 VB6 IDE，我们最初是从 WinXP 开发的。

问题是与 WinXP 中的 VB6 IDE 完全相同的 RegFree Com 配置在 Win7 中不起作用。（安装编译的可执行文件可以完美地工作）。我们收到一般的“ActiveX 组件无法创建对象”错误。我使用了 Fuslogvw.exe 和 SxSTrace.exe，我检查了 Windows 日志，但没有错误消息解释为什么对象的实例化失败。

那么，我还能做些什么来找到这个问题的原因呢？

我正在尝试提供一个 COM 对象，该对象可用作我无法控制的可执行文件中的对象的替代品。我用所有相同的接口创建了这个 COM 对象的实现。我希望只能偶尔使用此替换，因此我不希望它的注册替换原始对象。

通过修改可执行文件的清单以在我的 dll 中查找 com 对象而不是通过注册表查找原始对象，我可以让可执行文件加载我的 COM 对象而不是使用无注册 COM 的原始对象。

到目前为止，一切都很好。但是这样做需要修改可执行文件中的清单文件。我不希望此更改是永久性的，并且由于可执行文件通常安装在“程序文件”中，因此还需要管理员权限才能更改此文件。

理想情况下，我想要的是保持原始可执行文件不变。然后，当需要时，我创建的单独启动程序将使用重定向到我的 com 对象的清单加载请求的可执行文件，而不是可执行文件中的原始清单文件。

这样的事情可能吗？或者也许是一种更好的方式来做我想做的事情？

注意：我可能无法在我具有写入权限的位置更改清单并制作可执行文件的副本，因为我事先不知道该可执行文件的所有依赖项将是什么（它可能需要来自同一目录，或来自子目录的数据文件）。我可以将修改后的可执行文件的工作目录设置为原始可执行文件的目录，但如果可执行文件根据其文件位置执行任何操作，它将中断。

我正在开发许多使用 RegFree COM 激活的应用程序，除了其中一个应用程序是使用使用 JIT 类型编译器的旧技术运行之外，一切都运行良好。

为了让 RegFree COM 工作，我必须为启动可执行文件提供一个清单（如果我错了，请纠正我）并列出我的依赖项。我所有的其他应用程序都是内部构建的，我可以完全控制我的清单（创作，如果我嵌入它，如果我将它并排放置，等等）。但是这个 JIT 编译器（ala Java JRE）不是我的，它已经包含（嵌入）一个清单。

我已经提取了清单（使用带有 -inputresource 和 -outfile 的 MT），对其进行了修改并重新嵌入。它按预期工作。但是，由于对这个可执行文件没有所有权，我担心这种操作的合法性（修改第三方的可执行文件并重新分发它！）并希望避免这样做。另外，我担心在某些时候这个可执行文件可能会被第三方签名，因此修改嵌入式清单会破坏签名。

有没有办法让 sxs-loader 先寻找另一个清单？似乎如果它找到一个嵌入的，它默认采用它（在大多数情况下这很好）。我可以提供一个配置文件或任何可以跳过嵌入式清单并使用我并排提供的文件（myExe.exe.manifest，而不是 myExe.exe 中的 RT_MANIFEST 资源）吗？

我将首先解释我正在尝试做什么（以及为什么），然后再深入了解细节。

我试图让注册免费 COM 激活在编译 JIT 的语言的上下文中工作。我使用 Reg-Fre COM 是因为我想避免注册我的 COM 组件，并且希望这个应用程序可以在没有管理权限的情况下安装。

JIT 编译器是主要的可执行文件，已签名并包含嵌入式清单。默认情况下，最新版本的 Windows 更喜欢嵌入清单而不是外部清单（在 Windows XP 上正好相反）。由于 JIT 已签名，因此我无法在不破坏签名的情况下提取/修改/更新它的清单。此外，这会在我们的应用程序的维护中引入复杂性（始终确保我们嵌入一个新的清单）。修改我不拥有权利的程序也会产生法律影响。

所以，我的想法是尝试让 WinSxS 激活通过一个 Win32 包装库，我将为其提供一个列出依赖项的清单。作为概念验证，我决定制作一个简单的 VB6 应用程序、一个 C++ Wrapper 库和两个 COM 库（1 个在 .NET 中，1 个在 VB6 中）。包装器包含 3 种方法，一种调用 VB6 COM，一种调用 .NET COM，一种返回简单字符串。只要我的 COM 的所有内容都已注册，它当然可以工作。如果我取消注册它们，为 COM 提供清单并将它们作为依赖项添加到主可执行文件的清单中，它就可以工作。如果我取消注册它们，为 COM 和 C++ Wrapper 提供清单并将 com 添加为 C++ Wrapper 的依赖项，然后将 C++ Wrapper 作为主可执行文件清单中的唯一依赖项添加，它可以工作。

请注意，对于我的所有测试，我运行一个 Powershell 脚本来更改我所有文件的修改日期，确保触发激活上下文缓存（清单）。

从那里，我开始使用 SXSTrace.exe 进行调试并设置 COMPlus_LoadLogDir 变量。我发现如果我的清单是外部的，它永远不会被考虑在内。我还发现，如果我将它嵌入到 .DLL 中，sxstrace 会显示它已找到、已解析并且已找到依赖项、已找到它们的清单，并且我在日志中获得了通常成功的上下文激活行。

然而，即使日志说，我的 COM 调用仍然没有通过。当调用 .NET COM 调用时，我在 COMPlus_CLRLoadLogDir 配置路径中得到一些输出。

在这种情况下，我没有得到任何输出。

一旦我将仅将我的 C++ Wrapper 列为我的主要可执行文件的依赖项的清单添加到我的主可执行文件中，一切都会重新开始工作。我从 SXSTrace 得到了类似的输出，但现在 COM 调用工作了。如前所述，在所有情况下，C++ Wrapper 的简单字符串方法都有效。这意味着即使我的主可执行文件中没有清单，它仍然可以找到我的 .dll 并调用它。如果我没有完整的清单链，似乎 COM 不起作用：Application.Manifest > Wrapper.Manifest > COMs manifests

所以，这里有两件事...... 1.我正在尝试做的事情甚至可能吗？（仅在属于我的 DLL 的清单中列出了依赖项，而不涉及主可执行文件的清单） 2. 如果可能的话，我可能只是遗漏了一件小事来让一切顺利进行......它是什么？:)

如果有人有兴趣尝试使用 em 的东西，我可以提供我所有的代码/可执行文件作为示例。

您可以使用免注册 COM来避免向注册表注册 COM dll。

我目前试图弄清楚的是，当您尝试使用的组件也独立注册到 Windows 注册表时，这是否仍然应该工作。

例子：

但是，另一个版本的 pdm.dll也可能由另一个程序在注册表中注册。

MyApp.exe 然后将使用哪个版本？注册表中的一个还是清单中引用的程序目录中的一个？

这应该支持吗？

看着免注册的 COM，我仍然不清楚您是否可以只使用任何现有的、完全不知道的 COM 组件（*）并通过添加正确的清单文件以免注册的方式使用它。

这应该在所有情况下都有效。

他们所说的公寓的东西（ ）是怎么回事？comInterfaceProxyStub

(*) : (例如，一个 ocx 文件或另一个进程内 COM 服务器 DLL，它应该与regsvr32

TL;DR生成的所有注册表项是否都regsvr32需要出现在 SxS 无 reg-COM 清单中，反之亦然？

我正在尝试为第三方组件获取免注册 COM。

阅读 该主题，我发现提到了 几个元素，可以放入清单中：

从 docs中，我们可以将以下标签添加到清单中以描述 COM 组件：

• assemblyIdentity-据我所知，这实际上只是描述了“抽象程序集”
• comClass- 描述 COM 类（IID 接口）。看起来，这总是需要的。
• typelib- 什么时候？
• comInterfaceExternalProxyStub- 什么时候？
• comInterfaceProxyStub- 什么时候？

从其他文档中，HKEY_LOCAL_MACHINE\SOFTWARE\Classes我们可以观察到 COM 注册表项有几个类别：

• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CLSID} 我假设大致对应comClass
• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{IID}将对应于任何一个 comInterface[External]ProxyStub，但我真的不知道何时使用哪个（或两者）
• 哪个注册表条目对应于typelib清单条目？？

使用regsvr42来提取我试图 regfree 的 dll 的东西会产生一个清单，其中只包含comClass条目，没有 typelib 或 ProxyStub 条目。（我交叉检查了写入的键，有问题的 DLL pdm.dll，MS 的进程调试管理器只写入这些键，也就是说，注册表中没有明显的类型库或代理存根信息。）

如果注册表只包含与此相关的信息，comClass那么是否意味着此信息在 SxS 清单中就足够了，或者清单中可能需要其他信息？

顺便说一句，我注意到注册表包含 aVersionIndependentProgId和 a ProgId，最后附加了一个版本号。清单只有一个ProgId条目，并且文档状态：

progid：与 COM 组件关联的版本相关的编程标识符。ProgID 的格式是 <vendor>.<component>.<version>.

但文档也指出

comClass元素可以将元素作为子<progid>...</progid>元素，其中列出了版本相关的 progid。

他们说progid 属性应该是与版本无关的。

那么，放在这里什么呢？当客户不请求特定版本时，这是否重要？

我面临的问题基本上在这里描述，即：

• 我有一个使用第 3 方进程内 COM 组件 dll 的 DLL。
• 我想将免注册 COM 与该进程内组件一起使用。
• 我想在这个 DLL（而不是主 EXE）中嵌入并使用一个 manfest，以便我可以以无注册的方式使用第 3 方组件。
• 我从组件中使用的接口是通过调用来激活的CoCreateInstance。
• 第 3 方 COM 组件没有任何进一步的 (COM) 依赖项，并且不依赖或不需要隔离。

我看到简单地将清单嵌入到我的 DLL 中是行不通的，如链接问题中所述，我需要手动切换激活上下文。

我不明白的是我需要在何时何地切换激活上下文：我是否只需要将我的调用包装CoCreateInstance在 (*) 之类的东西中CActCtxActivator ScopedContext，还是需要将所有调用包装到第 3 方组件中？_{（据我所知，这ISOLATION_AWARE_ENABLED是应该提供帮助的。）}

那么，在使用免注册 COM 时，需要在哪里切换Activation Context呢？

(*) :或AFX_MANAGE_STATE(AfxGetStaticModuleState());(**) 或其他。

(**)：实际上，AFX_MANAGE_STATE以前可以工作，但在“较新”的 MFC 版本中不再有效。参见，例如VS2012：删除了对 MFC 中活动上下文切换的支持？：

我们从 MFC 中删除了所有激活上下文支持，因为我们......我们在 MFC 本身内部使用了 Windows 隔离感知 API。

// 发布者：Pat Brenner，Visual C++ 库开发：2013 年 6 月 5 日，星期三，晚上 11:10