问题标签 [regfreecom]

我目前正在尝试使用免注册 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 没有内置帮助。隔离意识。

我正在尝试为我们的代码中用作免注册 COM 的一组 COM 对象生成清单。为此，我在 VS 2010 中创建了一个 VB 项目，并将 COM 对象 DLL 作为依赖项添加。问题是我没有看到它们在生成的清单中列为依赖项。我是否遗漏了一些简单的东西，比如项目设置来生成列出依赖项的正确清单？

Does anyone know which relation may exist between registration-free COM and drag/drop functionality?

Specifically, we have a huge C++ CAD/CAM application comprising a number of EXEs and several hundreds DLLs. Many of them serve as COM servers (both in-proc and out-of-proc) and/or clients, and also implement ActiveX controls.

The most of ActiveX controls and the main CMDIFrameWnd-based window of one of EXEs implement drag/drop functionality. ActiveX controls implement the both drop source and drop target, and the main window is only drop target, in particular, for files from Windows Explorer.

The drag/drop implementation is pretty standard and based on two data members derived from COleDataSource and COleDropTarget for drop source and drop target respectively. The COleDropTarget-derived member is registered with respective window in the window's OnCreate method. It also overrides OnDragEnter, OnDragOver and OnDrop methods in a similar way. Namely, the system-supplied COleDataObject parameter is asked for specific format (in particular, CF_HDROP), and in the case of positive answer, the data (e.g., file path) is extracted from the clipboard. The code looks like the following:

The drop source implementation is also straightforward and looks like the following:

where prv_BeginDrag() function collects dragged data, packs it and puts on the clipboard by calling SetData method from the m_pOleDataSource object's IDataObject interface.

The all this stuff worked perfectly until it was decided to make the whole application registration-free. It took me three months to force the application run isolated (without registration of COM components) by embedding manifests, launching out-of-proc COM servers on demand and altering CLSID of some classes in order to separate instances of the same server launched from different folders. At last it begins to work - but without drag/drop functionality, despite it wasn't even touched by my changes.

On the drop target side, when I drag file from Windows Explorer, depicted above call to COleDataObject::IsDataAvailable returns false, although before my changes returned true. At the same time, if I add a single line of code "DragAcceptFiles();" to the main window's OnCreate method, drag/drop begins working via the standard CFrameWnd's WM_DROPFILE message handler.

On the drop source side, the dragged data are successfully packed and placed on the clipboard, but COleDataSource::DoDragDrop method fails, because a call to ::DoDragDrop API inside MFC implementation returns REGDB_E_CLASSNOTREG "Class not registered" result.

It means, that COM activation changes somehow influence drag/drop behavior. How?

P.S. 1) The EXE, to which I drag files from Windows Explorer, has in its project properties "UAC Execution Level = asInvoker". As far as I understand, it tells that the EXE will run at the same UAC level as Windows Explorer when launched by double-click on the file.

2) Quite surprisingly, although drag/drop stopped working with symptoms described above, Copy/Paste continues work well, despite the both technologies have similar implementation.

3) I believe, that if find out when ::DoDragDrop API returns "Class not registered" error, and which class it is looking for, it would be possible to solve the problem.

Thanks for help, Ilia.

我有一个 COM 可见的 .NET 类，它公开事件并从 VB6 中使用。在过去的几天里，我一直试图让它与 regfree COM 一起工作，但没有成功。

• 当事件从原始线程触发时，VB6 事件在 regfree 模式下运行。
• VB6 事件在注册类型库时从另一个线程触发时运行。（regasm /tlb /codebase 后跟 regasm /codebase /unregister，后者不会取消注册 tlb）

当在 regfree 模式下从另一个线程触发时，它会引发异常，因此永远不会执行 VB6 事件代码。

我可以想到两种情况：1）清单缺少与 tlb 注册相关的内容，或者 2）在创建新线程时丢失了激活上下文。不幸的是，我不知道如何找出是哪种情况，或者甚至可能是由其他原因引起的。

下面是一个显示我的问题的基本示例。

清单（VB6 可执行文件）

清单（C# DLL）

C#（平台目标：x86）

VB6

我有一个用 C# 编写的 DLL 并设置为 COM 可见性。我将它设置为并行程序集，并且可以成功地将应用程序部署到客户端 PC，无需注册。我的问题与开发PC有关。是否可以以类似的免注册方式针对 DLL 进行编译，或者是否需要在开发机器上进行注册？我尝试通过Project -> References菜单直接添加 DLL，并收到一条错误消息，指出“无法添加对特定文件的引用”。该 DLL 与 .vbp 文件位于同一目录中，我尝试在存在和不存在客户端应用程序清单的情况下添加 DLL。

我目前正在开发一个混合的本地/托管应用程序链，它采用免注册 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当试图从该特定线程停用激活上下文 () 时，似乎存在某种访问冲突。所以我想没有直接的方法来处理这种麻烦，除了在每个包装的调用中激活和停用激活上下文。任何可以证明并非如此的建议仍然受到欢迎。

我必须在 C++ DLL 中使用 VB (COM) DLL。我想出了如何从 C++ DLL 访问 VB (COM) DLL 并且它可以工作。

现在我遇到了必须使用隔离 COM/无注册 COM 的问题，因为我无法在每台必须使用它的 PC 上注册 DLL。

我想出使用清单文件来实现这一点，但我无法让它工作，我不知道出了什么问题。

我有一个名为 AccConnVB.dll 的 VB DLL，其中包含以下 AccConnVB.manifest 文件：

以及一个名为 AccConn.dll 的 C++ DLL，其中包含以下 AccConn.manifest 文件：

#define我的C++ DLL_WIN32_DCOM在其 stdafx.h 中，#import在 AccConnVB.tlb 中带有no_namespace.

以下是来自 C++ DLL 的方法：

我确保一切都可以使用已注册的 AccConnVB.dll，但在未注册的计算机上使用它会失败。

清单文件是通过在 cmd.exe 中执行 mt.exe 来嵌入的，其中包含以下行：mt -manifest H:\AccConnVB.manifest -outputresource:H:\AccConnVB.dll;#1, 分别用于 AccConn.dll 和 AccConn.manifest。

没有其他设置，访问 AccConn.dll 时，AccConnVB.dll、AccConn.manifest 和 AccConnVB.manifest 在同一个文件夹中。

我按照这里的演练并尝试了它的一些变体，但没有任何效果。

提前非常感谢大家！

附件一：

AccConn.manifest：

AccConnVB.manifest：

附件二：

OfficeConn.manifest - C++-DLL - （更改名称）：

OfficeConnVB.manifest - VB-DLL - （更改名称）：

我们在 VS 2008 中有 VC++ 项目，在 2010 年有 Wpf 项目。我们希望将它们都迁移到 Visual Studio 2015。

我们面临的最大问题是，新用户需要安装我们的软件时，他需要安装安装 VC++ Redistributable Package 的先决条件，这需要管理员权限。然后他需要通过 clickonce 服务器安装我们的应用程序。

我们想简化这部分 - 安装 VC++ Redistributable Package。

新的 2015 VC++ Redistributable 是否可以安装在我的应用程序路径中，而不需要管理员权限？我找不到下载 VS 2015 VC++ RP 链接的链接 - 请提供。

我从下面的链接中得到了使用 /MT（静态链接）的建议，但我们希望应用程序是稳定的（因为我们也发送补丁），我们不希望库冲突。

https://social.msdn.microsoft.com/Forums/vstudio/en-US/a8d4ca59-c295-43bf-b34e-518fe2f7977c/vc-2015-redistributable-package?forum=vclanguage#667db896-f517-4fa5-b5b7- b5b0c3d12d52

请帮忙。

We have a suite of components which offer the same set of interfaces. While investigating the possibility of client code using registration-free COM, we stumbled upon this problem. One client may use different implementations of the same inteface, depending on configuration provided by the user. Therefore, it must include a dependency for each one of these components. Each one of these components contains a comInterfaceProxyStub element registering the exported component interface. That is, we have many components with a comInterfaceProxyStub exporting the same set of interfaces, which they all implement. It seems this fact causes an error at activation time. ststrace.exe is not clear but it seems it is refusing to "register again". What are we missing? Is it supposed to be an error trying to activate a second component with a comInterfaceProxyStub element for an interface already "registered"?