曾几何时,一位年轻的,天真的工程师认为将自己的应用程序的一些function分离成用C#编写的COM组件是个好主意。 Visual Studio拥有所有的工具,对吧? .NET实际上是为此而做出的,对吧? 哈! 他说,这将是容易的。 我将有组件的体面的分离,使业务逻辑远离前端,并与COM,我将能够在任何地方使用它! 他愉快地在项目属性中检查了register for COM interopcheckbox的register for COM interop ,暴露了他想要的分类,然后继续前进。 哦,这样的select做出的审判。 现在这位年轻的工程师,更有经验的人现在不会希望这样的人了。 然而,他肩上的负担却是沉重的, 他希望减轻负荷。 WiX是一个用于从XML生成Windows Installer文件的工具。 这吸引了他 – 它可以很简单地复制一些正确的Windows安装程序文件所需的大部分代码,只需从less量configuration文件中复制即可。 他的目光正在抬头。 使用WiX 2.0,他可以轻松生成注册C#COM对象所需的文件。 这涉及到使用工具tallow。 他会做如下的事情: tallow -c -nologo MyComExposedLibrary.dll > MyComExposedLibrary.wxs (最初这是手动完成的,但最终我将这些步骤logging到一个小工具中,设置最终目录ref ID,组件ID,文件ID,GUID和代码库)。 然后,随后的安装程序将安装,如果应用程序工作,将会有欢乐的庆祝。 它没有。 这位年轻的工程师多年来一直在研发PC和testing安装PC的差异。 “所有registry项都是一样的!” 他会惊呼。 “MyComExposedLibrary的一切都注册了,我发誓! 除此之外,事实并非如此。 在第三天的黎明之后,他意识到还有另一个Visual Studio注册的对象,他的安装程序不是:MyComExposedLibrary.tlb文件。 显然,Visual Studio一直在注册这个文件,在HKLM\Software\Classes\Interfaceregistry项中创build其他子项,并在HKLM\SOFTWARE\Classes\TypeLib注册typelib。 Tallow没有任何帮助,抱怨说.tlb不是一个文件夹。 也不是WiX 3.0testing版 – 这似乎有更多的问题让事情工作。 我也给了热火一个尝试。 这生成了registry元素和类元素。 […]