我有一个第三方库可以与一块硬件对话。供应商提供了一个示例（VS）解决方案，一个演示调用的C ++ MFC应用程序 - 这个应用程序在我们的机器上运行良好。它调用初始化函数，要求串口HANDLE，然后进行一些通信。所有笨拙的海鲂。
当我从我们自己的硬件通信C ++项目（在具有相同硬件的同一台机器上）链接到库时，它编译并链接并运行正常，初始化返回值为“ok”并且它至少完成了某些操作因为正确返回了可用串口的数量。
但是当我用参数（uint）2（6中的第二个，绝对是正确的）调用开放串口函数时，我得到了一个NULL HANDLE。我已经按照相同的顺序对示例代码进行了精确的库调用，但示例代码返回非NULL并因此可以使用HANDLE，因此可以进行通信。
我不知道问题是什么。是什么阻止我逐渐从有效的东西移动到没有的东西是示例代码是MFC exe（我从未使用过MFC）和我们的硬件通信C ++项目是一个支持clr的DLL。在我看来，项目设置之间存在大量差异，并且包括每个项目所需的内容。我曾尝试将现有代码用作新独立CLR项目的模板，但它需要对项目设置进行如此多的更改，并且包含几乎没有可比性的文件，除非我能够，否则我不想继续这样做找到一些证据表明这可能实际上是问题的根源。
所以：我获得了一个带有单个项目的解决方案 - 一个带有“Project Defaults”的C ++项目：Application.exe，在共享DLL中使用MFC，不使用ATL，使用多字节字符集，没有公共语言运行时支持，没有整个程序优化。这个项目使用了我给出的相同的库文件（* .h，* .lib和dll）并生成一个exe，它返回一个非NULL句柄（我在Debug中直接验证了这一点），因此可以进行通信与设备。
我们的应用程序中与其他硬件通信的硬件通信项目具有“项目默认值”：动态库（.dll），使用标准Windows库，不使用ATL，使用Unicode字符集，公共语言运行时支持（/ clr），没有整个程序优化。
我的问题是，当我从/ clr硬件通信项目引用它们时，为什么这些相同的库文件无效？也就是说，库可以对它的创建有一些“记忆”，这意味着它可以与一个而不是另一个一起工作（记住代码编译和链接，至少做了某些东西，因为它返回true从初始化功能，并告诉我正确有6个端口）？或者，鉴于库正在MFC应用程序中工作和通信，这是否意味着我应该能够从clr项目中引用它没有问题，并且我们还有其他原因导致NULL串口问题（这是完全可能的）？
答案 0 :(得分：0)
如果没有实际代码或lib，这只是猜测问题。
我不是VC / MFC用户，但我也遇到过类似的问题：
由于x86 / x64不兼容？
检查DLL和EXE是否针对同一平台两者必须相同（x86或x64）以及使用DLL的exe当然其他硬件处理因WOW64仿真器而变化很多（通常需要一些x64挂钩） 。此类 GUID 可能与我在某些USB驱动程序中找到的不同。
同时检查是否未多次从lib初始化/导入COM类
它的行为也相似，所有函数都不是NULL，但只找到 NULL 句柄的真正HW。我发现这个问题与'MS'Kinect驱动程序实际上是JUNGO：）