问题标签 [tlbimp]

我正在尝试将 Windows Mobile 6.0 C# 项目放在我们的持续集成服务器 (Jenkins) 上。

尝试编译引用 TLB 的项目时出错： ResolveComReferences总是返回TYPE_E_LIBNOTREGISTERED。即使在不同的开发者之间传递项目，也必须再次添加引用。

我发现了一些关于可以在项目文件中完成的更改，使用COMFileReference而不是COMReference.

有没有办法在不修改 .csproj 文件的情况下解决这个问题？

我有一个 CoClass，描述如下：

所以我的问题是：

1. 为什么tlbimp只暴露IFoo接口，同时oleview.exe显示两个接口？
2. tlbimp只公开[default]接口，为什么？（根据 MSDN [default] “旨在供宏语言使用。”）
3. 如何在 MIDL/COM 中建模这种情况？我应该使用关联而不是继承吗？

我有一个 ActiveX COM 控件及其源代码。我想更改方法的输入参数之一，所以我更改了 IDL 等并生成了 COM DLL 和 TLB。

但是当我在 .NET 项目中导入 COM DLL 时，该方法保留了它的旧签名。所以我尝试使用 AXIMP 生成 ActiveX DLL（虽然都是一样的，但我想试一试）。

该方法的签名仍然没有更改为我更改的内容。

但是，当我使用生成的 TLB 文件中的 TLBIMP 生成互操作 DLL 时，方法签名正确更改。

我哪里错了？

谢谢。

假设我们在 VS 2005 (VB .Net) 中有一个 .NET 项目。该项目使用非 GUI COM 对象。当我添加对该对象的引用时，VS 会创建互操作 dll。但是我在另一个项目中向 COM 对象添加了新方法。如何在不显式调用的情况下更新互操作 dll tlbimp？我希望 Intellisense 显示此 COM 对象中的新方法列表。

I have inherited a Microsoft Visual C++ COM project which is a dependency of a core C# application I work with. When recompiling the project and regenerating the interop DLL (using tlbimp), several methods in my library that take in an OLE_HANDLE change their signature from the previous version of my interop DLL.

I wasn't around when the previous interop was generated, but it was almost certainly compiled under VS2005 on Windows Server 2003 / Windows XP. My workstation is now Windows 7 using Visual Studio 2010 (C++ Visual Studio Compiler version 16.00.40219.01 for x64).

This is the generated C# interface for the original and new DLL (using ILSpy):

New Interface (second parameter is marshaled using the ComAliasName attribute & as int):

Old Interface (second parameter is uint):

As far as I can see, the input IDL file hasn't changed and there don't seem to be any #includes / conditional statements that would affect the definition of an OLE_HANDLE.

Whenever the methods in question are invoked, an AccessViolationException is thrown.

Does anyone have any ideas why the generated interface may have changed (not sure if any changes in MIDL/TLBIMP would result in this behaviour) or how I might start to debug this further?

Header:

C++ source for method:

.NET 2.0 项目引用了使用“EXTRA”的 Windows XP，但在 Windows 7 中，Attachmate 软件正在使用 Attachmate Reflection，似乎人们被告知要摆脱“EXTRA”并替换为“外部司令部”

我还在研究它，但我想看看是否有人有这个问题。

EXTRACOM.tlb 我尝试添加并得到一个

我有一个旧版 VB 6 应用程序，WriteProfileString它仅用于与 16 位版本的 Windows 兼容。

我正在将其迁移到功能等效（即完全克隆）的.NET 应用程序中。这需要我使用TlbImp.exeWriteProfileString从COM 对象的 TLB 文件生成一个 Interop 程序集。这是一项要求，不能使用 P/Invoke。

当我这样做时，TlbImp.exe 会生成一个空程序集。

WriteProfileString具有以下 IDL：

幸运的是，微软已经开源了名为 TlbImp2.exe 的下一个版本的 TlbImp.exe。
我能够通过代码进行调试，发现 TlbImp.exe 和 TlbImp2.exe 都没有从模块中导入方法。为了让 TlbImp2.exe 导出模块的静态方法，我不得不修改代码。

我不得不更改ConvModule.cs文件：

并将以下方法添加到ConvCommon.cs：

所以现在它正确地导出了方法，但我仍然想知道为什么它没有首先导出这些方法。

这是导出程序集的代码：

它生成一个带有抽象成员的静态类。这没有任何意义。当然，我可以更改代码以不同方式导出它，但为什么 TlbImp2.exe 首先要这样做？

我假设它以这种方式导出它，因为它导出了模块的常量。我对吗？我应该对该方法应用哪些修饰符WriteProfileString以确保它可以与互操作一起使用？

I want to run a prebuild target which I'm coding up in a csproj. This needs to run tlbimp to produce a dll my project references.

I'm trying to exec tlbimp, but am getting errors that it can't be found. Is there an msbuild variable or environment variable I can use to deduce the path to it?

我正在尝试为sbtsv.idl（它包含在 Windows 8 SDK 中）创建一个 C# inproc 服务器。我发现的几乎每条指令都告诉您使用MIDL创建.tlb文件然后tlbimport创建代理 dll。

但是，如果 IDL 不包含library节，则不会.tlb生成文件，并且sbtsv.idl不包含library节。

我尝试创建自己的 IDL 文件，该文件声明了我想在库中创建的接口

但是，当我尝试运行它时，MIDL出现以下错误

我想我将被迫手动编写类和接口，但我想检查一下我是否做错了什么可以让它工作。

使用该工具导入基本类型库tlbimp.exe总是会为每个coclass. 例如这个 IDL 描述

结果是：

• 一个接口IFoo作为 COM 接口的表示，
• BarClass作为 COM coclass 的表示的类和
• 一个接口Bar，用CoClassAttribute.

Bar和的 GUIDIFoo相等的地方。MSDN关于这个主题的状态：

此接口与 coclass 的默认接口具有相同的 IID。使用此接口，客户端始终可以注册为事件接收器。

这是我在这个主题上发现的唯一内容。我知道，由于CoClassAttribute，我可以使用接口来创建实际类的实例。我也知道（实际上）我可以简单地使用它BarClass来创建类的新实例。我不明白的是，为什么导入过程会生成Bar接口，即使coclass没有定义事件源，因此没有事件接收器可以连接到它。

是否可以删除此示例中的Bar接口¹或是否还有其他风险，我尚未考虑？

^{1 _{例如通过拆卸互操作组件。}}