问题描述

曾几何时，一位年轻、天真的工程师认为将他的应用程序的一些功能分离到一个用 C# 编写的 COM 组件中是个好主意.Visual Studio 拥有所有的工具来做到这一点，对吧?.NET 实际上就是为此而生的，对吧?哈！他说，这会很容易.我将有良好的组件分离，使业务逻辑远离前端，并且使用 COM，我将能够在任何地方使用它！他兴高采烈地检查了项目属性中的 register for COM interop 复选框，公开了他想要的类，然后继续前进.

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.

随之而来的是 WiX，这是一种用于从 XML 生成 Windows Installer 文件的工具.这引起了他的兴趣——它可以很简单地从少数配置文件中复制正确的 Windows 安装程序文件所需的大部分代码.他的视线正在抬头.

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.

使用 WiX 2.0，他可以很容易地生成注册 C# COM 对象所需的文件.这涉及使用工具动物脂.他会做如下的事情:

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:

tallow -c -nologo MyComExposedLibrary.dll > MyComExposedLibrary.wxs

然后将其修复(起初这是手动完成的，但最终我将这些步骤记录到一个小工具中，设置最终目录 ref id、组件 ID、文件 ID、GUID 和代码库).

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.

它没有.

几天来，这位年轻的工程师倾述了他的开发 PC 和测试安装 PC 的差异.所有的注册表项都是一样的！"他会惊呼.MyComExposedLibrary 的所有内容都已注册，我发誓！"

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!"

但不是.

在第三天的黎明，在经历了许多山露之后，他意识到 Visual Studio 正在注册另一个他的安装程序没有注册的对象:MyComExposedLibrary.tlb 文件.

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 显然一直在注册这个文件，在 HKLMSoftwareClassesInterface 注册表项中创建额外的子项，并在 HKLMSOFTWARE 中注册类型库类TypeLib.

Visual Studio, apparently, had been registering this file all along, creating additional subkeys in the HKLMSoftwareClassesInterface registry key, and registering the typelib in HKLMSOFTWAREClassesTypeLib.

Tallow 没有提供任何帮助，抱怨 .tlb 不是它摸索的文件.也不是 WiX 3.0 测试版——这似乎有更多的问题让事情正常工作.

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.

我也尝试过热火.这会生成注册表元素和类元素.我清理了 heat 的输出，然后去编译它，但是得到一个不同的错误: error LGHT0130 : The primary key <uuid here>在表 'Registry' 中重复.问题是，据我所知，uuid 实际上并不存在于我的任何 wxs 源文件中.如果我改变了我的特征元素中的组件引用顺序，一个不同的 dll 组件会给出该错误.由于我未能成功编译项目的 WiX 3.0 版本，因此我无法确认 heat 是否提供了正确的输出.

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!

所以，我的好伙伴、Windows 爱好者和 WiX 用户，有两个问题:

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

• 类型库是 WiX 可以本地注册的东西吗?如果有，怎么做?
• 如果没有，使用 Windows 安装程序注册类型库的正确方法是什么?

另外，我想作为这一部分的另一部分，Visual Studio 如何确定如何注册类型库?(看起来 关于 typelib 注册的 MSDN 库文章有所需键的名称，但我仍然需要弄清楚如何获取 uuid.(来自 Larry Osterman 撰写的关于 typelib 和 COM 注册的博客文章.)阅读更多内容，我可能需要手动注册这些位，但我希望不会……

Also, I guess as another part of this, how does Visual Studio determine how to register the typelib? ( 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...

我评估了 regasm/regfile:MyDll.dll MyDll.dll 的输出.看起来这些是 wix 为 dll 生成的相同键.Regasm 的另一种模式，regasm/tlb: 为程序集生成并注册 typelib，但是，

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] 生成指定名称的reg文件而不是注册类型.这个选项不能与/u 或/tlb 选项一起使用

/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

似乎/regfile 开关与/tlb 开关不兼容.哈哈哈哈哈！

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

进一步更新:看起来您实际上并不需要包含 .tlb 文件.根据这篇关于 wix 的 typelib 的帖子元素，MSI可以创建/注册它作为设置过程的一部分.这一切都归结为通过获取正确的属性来配置 WiX 文档以实际安装它.

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.

我后来发现，您可以直接在 .tlb 上使用 heat 获得正确的属性！请参阅此 SO 问题了解更多信息.

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

推荐答案

您应该使用位于您正在使用的版本的 bin 目录中的 Heat (WIX 3.0).看看这个 blog 帖子，我们在这里使用它来注册我们所有的 COM 对象，通过创建一个 wix 片段...

You should use Heat (WIX 3.0) located in the bin directory of the version you are using. Have a look at this blog post, we use it here to register all our COM objects, by creating a wix fragment...

类似

heat file MyComExposedLibrary.dll -out MyComExposedLibrary.wxs

阅读您的编辑后，我将创建一个带有 wix 的基本 msi，它只安装 com 对象，看看是否有效......然后你就会知道要攻击哪个战场......

After, reading your edit, I would create a basic msi with wix that installs the com object only, see if that works ... then you'll know which battlefield to attack ...

这篇关于使用 WiX 安装程序复制 Visual Studio COM 注册的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！