复制Visual Studio中的COM注册与维克斯安装程序 [英] Replicating Visual Studio COM registration with a WiX Installer
问题描述
曾几何时，一个年轻的，天真的工程师认为这将是一个好主意，分离出一些他的应用程序的功能集成到一个COM组件，用C＃编写。 Visual Studio中把所有的工具来做到这一点，对不对？ .NET实际上是为这个做，对不对？哈！他说，这将是很容易。我有分量的体面的分离，保持业务逻辑从前端，并与COM，我就可以从任何地方使用它！他欢快地检查了注册COM互操作复选框在项目属性，暴露了他想要的classses，并继续他的方式。
呵呵，试验这样的选择进行。这位年轻的工程师，现在，更多的经验，现在不会在任何人希望这一点。然而，负担已经放在他的肩膀上，而负担仍然沉重。他看了看，以减轻负担。
随着来到维克斯，从XML生成Windows Installer文件的工具。这种好奇他 - 它可以复制，很简单，大多需要一个适当的Windows安装程序文件只是从极少数的配置文件code。他的目光在寻找了起来。
使用WiX的2.0，他可以很容易地生成注册一个C＃的COM对象所需的文件。这涉及到使用工具牛油。他会做类似如下：
牛油-c -nologo MyComExposedLibrary.dll＆GT; MyComExposedLibrary.wxs
然后，随后安装程序会安装并会有喜庆，如果应用程序的工作。
它没有。
有关天年轻的工程师倒在他的开发PC上的分歧，测试安装PC。 所有的注册表项都是一样的！他会惊呼。 对于MyComExposedLibrary一切都registerd，我发誓！
除，事实并非如此。
在第三天的黎明，经过许多山不露水，他意识到有一个更对象，Visual Studio中被注册，他的安装程序是不是：该MyComExposedLibrary.tlb文件
Visual Studio中，显然，已经注册该文件，一直以来，在 HKLM \ Software \ Classes下创建额外的子项\接口的注册表项，并注册了类型库 HKLM \ SOFTWARE \ Classes下\类型库。
乌桕给没有任何帮助，抱怨一个.TLB不是一个文件，它groked。也不是维克斯3.0测试版 - 这似乎有更多的问题，把事情的工作
。我也给了热火一个尝试。这个生成注册表元素和类元素。我清理热量的输出，然后去编译它，却得到了不同的错误：错误LGHT0130：主键＆LT;此处＆GT UUID;被复制的表'注册'。问题是，据我所知，这UUID实际上并不在我的任何WXS源文件存在。如果我在功能元件周围的元件编号顺序发生变化，不同的DLL组件给出了错误。因为我一直在成功得到一个WiX的3.0版本的项目编制的，我一直没能证实热与否给出正确的输出。
我删除一切从安装程序不同的是，会导致出现此错误并尝试再次编译组件之一。我得到了同样的同样的错误。 Arrugh！
所以，我的好人时，Windows爱好者，和WiX的用户，有属于两个问题：
- 是一个类型库的东西，维克斯可以本地注册？如果是这样，怎么 ？
- 如果没有，什么是注册类型库使用Windows Installer程序？ 的正确方法
此外，我想为这另一部分，如何Visual Studio的决定如何注册类型库？ （编辑：看起来在类型库登记 MSDN库文章有需要的键名，但我仍然需要弄清楚如何获得UUID的。（这是从的拉里·奥斯特曼的类型库和COM注册这个博客帖子。））读多一点，这可能就是我的手动注册这些位，但我希望不是......
我评估了 regasm /regfile:MyDll.dll MYDLL.DLL 的输出。它看起来像这些都是维克斯生成的DLL相同的键。 Regasm的另一种模式， regasm / TLB：其中，文件名＆GT; 生成并注册类型库的组件，但是，
/ REGFILE [：文件名]生成具有指定名称的reg文件 而不是注册的类型。此选项 不能与所使用的/ u或/ TLB选项
看来/ REGFILE开关与/ TLB开关不兼容。 Khaaaaaaaan！
进一步的更新：它看起来像你这样做不实际的需要的包括.tlb文件。 <一href="http://chenhaoyork.word$p$pss.com/2009/02/15/deploy-customized-arcmap-toolbar-via-wix-2/">According到这个职位上的WiX的类型库元素，微星可以创建/注册这是在安装过程的一部分。这一切都归结到配置维克斯文件须由获得正确的属性实际安装它。
我后来发现，你可以得到正确的使用属性上的热量直接.TLB！请参见这太问题的更多信息，。
您应该使用位于您所使用的版本的bin目录热火（维克斯3.0）。 看一看这博客的，我们在这里使用它来注册我们所有的COM对象，通过创建一个WiX的片段...
像
热文件MyComExposedLibrary.dll退房手续MyComExposedLibrary.wxs
后，阅读你的编辑，我会创建一个基本的MSI与WiX的，只有安装了COM对象，看看有没有什么工作......那么你就会知道在于攻击战场......
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:
tallow -c -nologo MyComExposedLibrary.dll > MyComExposedLibrary.wxs
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.
You should use Heat (WIX 3.0) located in the bin directory of the version you are using. Have a look at this blog, we use it here to register all our COM objects, by creating a wix fragment...
something like
heat file MyComExposedLibrary.dll -out MyComExposedLibrary.wxs
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 ...
这篇关于复制Visual Studio中的COM注册与维克斯安装程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
