Com 在MIDL中引用完整路径的ImportLib

我发现使用这种语法，我会得到一个编译错误：

importlib("MSADDNDR.dll");

给出的错误是：

error MIDL2337 : unsatisfied forward declaration : _IDTExtensibility2 [ Coclass '_Extension'  ]

但那是一种谎言。在前面的输出中，我们看到：

warning MIDL2015 : failed to load tlb in importlib: : MSADDNDR.dll

因此，如果我们更改属性以包含完整路径：

importlib("C:\Program Files (x86)\Common Files\Designer\MSADDNDR.dll");

它现在将正确编译。。。。但是这是引用32位DLL。假设我想要交叉编译？因此，我将

/amd64

选项指定给MIDL。这仍然可以成功编译。我找不到任何文档表明，为

importlib

使用可能错误的位DLL的完整路径会导致问题

其他人能否确认或否认是否存在潜在问题，或者是否有更好的方法避免嵌入完整路径

---

有趣的是，当我在

oleview

中加载生成的

.tlb

文件时，完整路径不再存在；这表明这不是一个问题，但我想确保是这样。

我非常确定类型库是位独立的；同样的方法适用于32位和64位环境。它作为资源附加到32位或64位DLL这一事实与此无关。也就是说，您可以使用告诉MIDL在哪里搜索导入的库，而不是将路径硬编码到源代码中。我们可以提供一个位独立的CLR DLL，但我们必须始终为同一个CLR DLL分别提供32位和64位TLB文件；

regasm.exe

、

tlbexp.exe

以及midl都提供了生成32位或64位TLB文件的选项。注册表甚至为

win32

和

win64

有单独的条目。这就是为什么IDL中32位DLL/TLB的完整pth不会对正在生成的TLB产生任何影响的原因。很高兴知道RE:

/I

-不确定这有什么帮助，因为32/64版本需要不同的路径。我猜这不是问题，因为COM不太关心目录。通常，它会根据GUID使用注册表找到一个类型库，这就是COM组件和类型库必须注册的原因。但是，我同意Igor的观点，即使用/I命令行选项比在源代码中硬编码路径更好。Re：它有多大帮助。无论您使用什么构建系统来设置

/amd64

选项，都会将

/I

选项设置为指向64位目录；而32位构建将指向32位目录。@PhilJollans如果它使用的是注册表，那么它本来就不需要完整路径，不是吗？也就是说，我肯定会使用

/I

而不是嵌入完整路径。