问题标签 [typelib]

我有一组用 Delphi.NET (.NET 1.1) 编写的库，我想在我的 Win32 (Delphi) 应用程序中使用它们。对于与性能相关的问题，我决定遵循 COM 路线。

有时，在重建 DLL 后，当我尝试实例化通过 COM 公开的对象时，Win32 应用程序在CreateComObject调用时挂起。我怎么解决这个问题？

为了通过 COM 公开 Delphi.NET 库，我在每个类减速上方添加以下属性：

编译 DLL 后，我生成一个TLB.pas文件，该文件包含 DLL 中所有公共和 COM 可见类和接口的定义。这个文件允许我更容易地在我的 Delphi Win32 应用程序中使用 COM 对象。最后，.dll我.tlb使用regasm.

我尝试注销并运行引用 DLL 的 Win32 应用程序；我预计会收到运行时错误，但应用程序再次挂起CreateComObject()。

我也尝试过注销和注册 DLL，但没有任何运气。

ps 我正在使用 BDS 2006

我有一些使用清单文件的应用程序（一些本机，一些 .NET），因此它们可以完全隔离部署，而无需任何全局 COM 注册。例如，对 dbgrid32.ocx com 服务器的依赖在 myapp.exe.manifest 文件中声明如下，该文件与 myapp.exe 位于同一文件夹中：

dbgrid32.ocx 与它自己的 dbgrid32.ocx.manifest 文件一起部署到同一文件夹：

这一切都很好，但是手动维护这些清单文件有点痛苦。有没有办法自动生成这些文件？理想情况下，我只想声明应用程序对 COM 服务器（本机和 .NET）列表的依赖关系，然后让其余的自动生成。是否可以？

Once upon a time, a young, naive engineer thought it would be a good idea to separate out some of the functionality for his app into a COM component, written in C#. Visual studio had all the tools to do that, right? .NET was practically made for this, right? HA! He said, this will be easy. I'll have decent separation of components, keeping business logic away from the front end, and with COM, I'll be able to use it from anywhere! He merrily checked the register for COM interop checkbox in the project properties, exposed the classses he wanted, and went on his way.

Oh, the trials such a choice made. The young engineer now, more experienced, would not now wish this upon anyone. However, the burden had been placed upon his shoulders, and the burden remained heavy. He looked to lighten the load.

Along came WiX, a tool for generating Windows Installer files from XML. This intrigued him - it could replicate, quite simply, most of the code needed for a proper windows installer file simply from a handful of configuration files. His sights were looking up.

With WiX 2.0, he could generate quite easily the files needed to register a C# COM object. This involved using the tool tallow. He'd do something like the following:

which would then be fixed up (at first this was done manually, but eventually I recorded the steps into a small tool set the final directory ref id, component ID, fileID, GUID and codebase).

Then, the ensuing installer would install, and there would be joyous celebration, if the app worked.

Which it did not.

For days the young engineer poured over the differences on his development PC and that of the test install PC. "All the registry keys are the same!" He would exclaim. "Everything for MyComExposedLibrary is registerd, I swear!"

Except, it wasn't.

On the dawn of third day, after many a mountain dew, he realized there was one more object that Visual Studio was registering that his installer was not: the MyComExposedLibrary.tlb file.

Visual Studio, apparently, had been registering this file all along, creating additional subkeys in the HKLM\Software\Classes\Interface registry key, and registering the typelib in HKLM\SOFTWARE\Classes\TypeLib.

Tallow gave no help, complaining that a .tlb wasn't a file it groked. Nor the WiX 3.0 beta - this seemed to have even more issues getting things working.

I also gave Heat a try. This generated registry elements and class elements. I cleaned up heat's output, and then went to compile it, but got a different error: error LGHT0130 : The primary key <uuid here> is duplicated in table 'Registry'. Problem is, as far as I can tell, that uuid doesn't actually exist in any of my wxs source files. If I change around the component ref order in my feature element, a different dll component gives that error. Since I have been unsuccessful at getting a WiX 3.0 version of the project to compile, I haven't been able to confirm whether or not heat gives the right output.

I removed everything from the installer except for one of the assembly that cause this error to appear and tried compiling again. I got the same same error. Arrugh!

So, my good fellows, Windows enthusiasts, and WiX users, there falls two questions:

• Is a typelib something that WiX can register natively? If so, how?
• If not, what's the proper way of registering a typelib with a windows installer?

Also, I guess as another part of this, how does Visual Studio determine how to register the typelib? (Edit: looks the MSDN library article on typelib registration has the names of the keys needed, but I still need to figure out how to get the uuid's. (This is from this blog post on typelib and COM registration by Larry Osterman.) ) Reading a bit more, It may fall to me to register these bits manually, but I hope not...

I evaluated the output from regasm /regfile:MyDll.dll MyDll.dll. It looks like these are the same keys that wix generates for the dll. Regasm's other mode, regasm /tlb:<filename> generates and registers the typelib for the assembly, but,

/regfile[:FileName] Generate a reg file with the specified name instead of registering the types. This option cannot be used with the /u or /tlb options

seems the /regfile switch is incompatible with the /tlb switch. Khaaaaaaaan!

Further update: It looks like you don't actually need to include the .tlb file. According to this post on wix's typelib element, an MSI can create/register this as part of the setup process. It all comes down to configuring the WiX document to actually install it by getting the right attributes.

I found out later that you can get the right attributes using heat on the .tlb directly! See this SO question for more information.

假设您有两个程序集（两个 dll）。第一个包含一个名为 Base 的类，第二个包含一个名为 Derived 的类，它公开继承自 Base。

当我在 Visual Studio 2005 中使用 tlb 文件创建 C++ 类时，我得到了 Base 和 Derived 类，但其中一个不是另一个的子类。似乎没有任何 IS-A 关系。是否有一个原因？

在询问了 Visual Studio 为注册 COM 库做了什么之后，很明显 VS 为 COM 注册做了两件事：

1. 注册 COM 库
2. 创建并注册类型库

Visual Studio 似乎使用 regasm.exe 进行此注册。对于第一部分（直接 COM 注册），使用tallowor heat（WiX 2.0 或 WiX 3.0）似乎可以正确获取所有基本 COM 注册信息。

但是，tallow/heat 似乎没有做的是设置类型库安装。可以使用 WiX 安装程序和 regasm.exe 创建自定义操作来执行此操作，但对于基于 Microsoft 安装程序的安装程序，调用自定义操作并不是最佳实践。

经过进一步研究，看起来 msi 具有在安装时生成类型库的能力。事实上，WiX 似乎对它有直接的支持！在文件元素中，您可以添加Typelib元素。事实上，这里关于 wix 的一篇文章有​​一个使用Interface元素填充 TypeLib 元素的示例。

Interface 元素似乎至少有两个必需的属性：

1. ID
2. 姓名

Larry Osterman 谈到了需要为 TypeLib 注册的接口的其他部分，这个接口条目似乎照顾了各个部分。Larry 说我们需要将 ProxyStubClassId32 指定为“{00020424-0000-0000-C000-000000000046}”，因此我们可以轻松添加它。

从那里去哪里以及为各种界面元素填写什么让我很难过。我已经继续并将 TypeLib 元素添加到我的 wix 文件中，并且它成功编译。不过，我对如何设置界面元素有点无能为力。我们需要做什么才能正确填写 TypeLib 元素，我可以使用哪些应用程序或工具来获取它？

wcoenen 下面的答案看起来很有希望......我要试一试。

更新：在下面发布我的最终解决方案作为答案。

我目前有一个在 Delphi 中创建的 Win32 类型库，我需要通过 .NET 使用、实现和重新公开它。将 TLB 带入 Prism 以实现接口所需的步骤是什么？

当使用heat（来自 Wix 3.0.4805.0）从 Visual Studio 生成的类型库中生成 Wix 文档时，我遇到了一个错误。弹出一个窗口，上面写着：

'heat.exe - 坏图像'

应用程序或 DLL c:\path\to\file.tlb 不是有效的 Windows 映像。请对照您的安装软盘检查。

但是当我们按下'ok'后，它会继续并成功生成

看起来wix bugboard 上的这个错误报告说它是在我之前的版本中修复的，但似乎不是. 他们说发生错误是因为它首先尝试将其作为 DLL 加载（失败），然后继续做正确的事情。

这发生在 Windows XP SP3 上。

有人知道解决方法吗？

我使用 VS2005 制作了一个简单的 C# DLL（这是一个更大项目的一部分）。我需要通过 VBA 代码在 Excel 中使用 DLL，因此我在程序集上使用 COM Interop。我正在尝试使构建过程自动生成必要的 TLB 文件，这样我就不需要在每次构建后转到命令行并使用 regasm。

我的问题是，虽然 DLL 编译和构建很好，但它不会生成 TLB 文件。相反，标题中的错误会在输出框中打印出来。

通过转到 VS2005 -> Build -> Output -> Check "Register for COM interop"中的项目属性，我已经获得了其他 DLL 来构建 TLB 文件。我还在AssemblyInfo.cs 中有[assembly: ComVisible(true)] 。

以下是问题 DLL 的源代码以及它为返回类型引用的 DLL 的摘要：

这里是 SymbolTable.dll 的摘要。它拥有 ProblemLibrary 使用的返回类型。

我正在尝试构建一个强命名的应用程序。它引用了我通过“添加引用”对话框添加的 COM 互操作库。已经有一段时间了，但我似乎记得在旧版本的 Visual Studio 中，有一个Wrapper Assembly Key File的项目设置。我似乎在 Visual Studio 2008 中找不到它？

我有一个 .NET dll，它有一些暴露给 com 的接口\类。在构建过程中会生成一个 .tlb 文件，并且该 tlb 被一些 c++ 代码引用。因此，编译器会为 tlb 生成一个 .tlh 文件。

当我在本地运行构建时，其中一个接口中的属性之一最终会在 tlh 中具有不同名称的相应方法。.net 代码中的属性称为 PropertyA，最终称为 get_propertyA，而 PropertyB 最终称为 get_PropertyB。发生这种情况时，我没有眨眼，只是使用了 tlh 中定义的方法并假设一切都是 hunky dory，但是当我提交这些更改时，构建对其他人不起作用，因为编译器生成了名为 get_PropertyA 的属性和get_PropertyB（注意 propertyA 中的大小写不匹配）。

两台机器上生成的 tlb 文件是相同的（根据十六进制比较器），并且 tlh 文件都是由相同的编译器版本生成的。

构建过程通过执行以下操作创建 tlb： regasm path\to\dll\Mydll.dll -tlb:path\to\output\mydll.tlb

任何想法为什么我的本地版本最终会出现名称不正确的属性？或者我能做些什么来解决它？

更新：我读到 tlbexp 将使用它找到的字符串的第一个版本，并且可以通过重新编译来改变。虽然我没有使用 tlbexp，但我想知道这是否是问题所在。我发现参数与我的方法（在其他方法中）同名，但开头是小写字母。所以我把这些都换了。重建，没有变化。所以我然后重命名了我的 COM 方法。重新构建并得到预期的缺失方法错误。将该方法重命名为原始名称，嘿，它似乎已修复。由于它现在似乎可以工作并且我不能让它再次失败，我无法尝试建议的解决方案，但我喜欢重命名的想法，以防将来发生这种情况。