MFC 和 /clr C++ 项目中的库

Posted 2023-02-16

【中文标题】MFC 和 /clr C++ 项目中的库

【英文标题】：Libraries in MFC and /clr C++ projects

【发布时间】：2014-01-23 11:51:07

【问题描述】：

我有一个 3rd 方库来与一个硬件对话。供应商提供了一个示例 (VS) 解决方案，一个演示调用的 C++ MFC 应用程序——该应用程序在我们的机器上运行良好。它调用一个初始化函数，请求一个串行端口 HANDLE，然后进行一些通信。所有的笨拙的多莉。

当我从我们自己的 Hardware Comms C++ 项目（在具有相同硬件的同一台机器上）链接到库时，它编译并链接并运行正常，初始化返回值为“ok”，它至少做了一些事情因为正确返回了可用的串行端口数。

但是当我使用参数 (uint) 2（6 中的第二个，绝对是正确的）调用打开的串行端口函数时，我得到一个 NULL HANDLE。我已经按照相同的顺序对示例代码进行了确切的库调用，但是示例代码返回一个非空值，因此可以使用 HANDLE，因此可以进行通信。

我不知道问题是什么。阻止我逐渐从可行的东西转向不可行的东西的原因是示例代码是一个 MFC exe（我从未使用过 MFC），而我们的 Hardware Comms C++ 项目是一个支持 clr 的 dll。在我看来，项目设置之间存在大量差异，并且每个设置都包含所需的内容。我曾尝试将现有代码用作新的独立 CLR 项目的模板，但它需要对项目设置进行如此多的更改并包含看起来几乎没有可比性的文件，除非我可以，否则我不想一直摆弄这个找到一些证据表明这实际上可能是问题的根源。

所以：我得到了一个带有单个项目的解决方案——一个 C++ 项目，其“项目默认值”为：Application.exe、在共享 DLL 中使用 MFC、不使用 ATL、使用多字节字符集、无公共语言运行时支持，无整个程序优化。该项目使用与我相同的库文件（*.h、*.lib 和 dll），并生成一个 exe，它返回一个非 NULL 句柄（我已直接在 Debug 中验证了这一点），因此可以进行通信与设备。

我们应用程序中与其他硬件通信的硬件通信项目具有以下“项目默认值”：动态库 (.dll)、使用标准 Windows 库、不使用 ATL、使用 Unicode 字符集、公共语言运行时支持 (/ clr)，没有整个程序优化。

我的问题是，当我从我们的 /clr Hardware Comms 项目中引用这些相同的库文件时，是否有任何原因无法工作？也就是说，库是否可以对它的创建有一些“记忆”，这意味着它可以与一个而不是另一个一起工作（记住代码编译和链接并且至少做了 something 它返回 true从初始化功能并正确告诉我有6个端口）？或者，鉴于库正在 MFC 应用程序中工作和通信，这是否意味着我应该能够从 clr 项目中引用它没有问题，并且我们还有其他原因导致 NULL 串行端口问题（这完全有可能）？

【参考方案1】：

没有实际代码或库，这只是猜测问题。

我不是 VC/MFC 用户，但我也遇到过类似的问题：

由于 x86/x64 不兼容？

检查 DLL 和 EXE 是否适用于同一平台，两者必须相同（x86 或 x64），当然还有使用 DLL 的 exe，否则由于 WOW64 模拟器（通常需要一些 x64 挂钩），硬件内容处理会发生很大变化.此外，类 GUID 可能与我在一些 USB 驱动程序中发现的不同。

还要检查 COM 类是否没有多次从 lib 初始化/导入

它的行为也相似，所有函数都不是 NULL，但没有找到真正的硬件，只是 NULL 句柄。我发现这个问题与实际上是 JUNGO 的“MS”Kinect 驱动程序有关 :)

【讨论】：

是的，抱歉，这基本上是一个“任何人都可以猜到答案”的问题。这是一个关于项目设置和库使用的问题——我相信两个版本中的 C++ 代码本质上是相同的。我现在将详细介绍您的建议。

继续并在独立的 /clr 应用程序上复制了正确的行为，因此在其他地方进行了搜索。为什么请求 HANDLE 返回 0 的问题的（回想起来，显而易见的）答案是端口已经打开并且正在被发现过程的其他部分使用。事实证明是这样 - 与 MFC 或 /clr 或任何东西无关。