问题标签 [wix]

背景：

我总是试图在我的项目中确保以下原则：

重新结帐后，开发人员应该能够仅使用组合文件夹的内容来完成所有与项目相关的任务。

显然，这并不总是可行的（例如用于 Windows 开发的 Visual Studio）。但是，我真的不喜欢安装任何特定于项目的第三方库或工具，如 log4net、NHibernate、NUnit 等。这有很多原因，包括：

• 对于给定的开发机器，您可能会处理多个不同的项目，所有这些项目都利用相同第三方库或工具的不同版本。
• 最小化环境设置要求使得设置新的开发人员或机器更加容易
• 有助于更轻松地维护自动化构建

假设/限制

• 我目前正在使用 WiX 3 beta，但如果有 2.0 或 3.0 的方法，请回复
• 我正在使用 Visual Studio 2005
• IDE 语法高亮不是必需的。

问题：

是否可以避免本地安装 WiX 工具集而使用平面文件？如果是这样，请解释如何。

也可以看看：

经过大量的试验和错误（主要是由于缺乏文档和示例），我设法创建了将自定义 DLL 作为并行程序集安装到 WinSxS 的 MSI 安装程序。只有一个问题：卸载会将所有文件（DLL、清单和目录）留在 WinSxS 目录中。我怎样才能或应该最好地清理它？我确信没有其他东西引用它。

我在某处读到 WinSxS 有一个自我清理过程，随着时间的推移会清理，但我找不到更多信息。你可以手动调用它来清理东西吗？

我看到的唯一其他方法是手动删除这些位。首先，您必须将所有文件（程序集、目录、清单及其各自目录）的所有者从 SYSTEM 更改为管理员帐户，调整权限并删除它们。注册表中还剩下一些部分（我认为 HKLM\COMPONENTS\DerivedData\Components 可能是一个地方），但由于 WinSxS 应该被视为不透明，因此很难找到任何信息。

是否有任何理由不设置安装以便始终完成主要升级并更改产品代码？

我发现支持不同类型的安装需要更多的代码，并且“修复”安装似乎更容易通过重大升级进行。此外，需要安装的应用程序不是很大，因此不需要“服务包”或补丁安装程序。

例如，我不想覆盖配置文件和其他一些文件，我应该使用 WiX 做什么？

我想部署我用 Visual Studio 2008 编写的 VSTO 3 Application Level Word 2007 插件。我看到 WiX 有一个名为 WixOfficeExtension 的扩展，看起来它可能具有此功能，但我找不到任何文档，我无法从源代码中辨别出它的目的。

以前有没有人尝试过这个，你能成功地完成它吗？

我有一个客户，我们的应用程序的 .msi 安装程序有问题。WiX 用于创建此安装程序。该应用程序在其他几十台机器上安装得很好，但在他的机器上它显示消息：

无法打开此安装包。请与应用程序供应商联系以验证这是否是有效的 Windows 安装程序包。

我的猜测是它是以下两种可能性之一：

1. 客户端计算机上的 Windows Installer 版本已过期。
2. 他拥有的 .msi 可能已损坏。

最可能的可能性是什么，或者还有其他我不知道的可能性？

我想我已经重现了用户的问题。如果我从命令 shell 运行MyFile.msi，然后它成功加载，那么我在日志文件中得到这个：

但是，如果我运行msiexec /i MyFile.msi /l*v MyLog.TXT，我会得到：

这显示了这个对话框：

无法打开此安装包。验证该包是否存在并且您可以访问它，或者联系应用程序供应商以验证这是一个有效的 Windows Installer 包。

所以这似乎是一个权限问题，但我不确定为什么以及如何解决它。我可能需要对 .msi 文件进行数字签名吗？

当 Wix 创建与现有快捷方式同名的快捷方式时，它会覆盖现有快捷方式。有没有办法检测现有的快捷方式并确保新的快捷方式具有唯一的名称？

例如，如果 Wix 在桌面上安装了快捷方式“MyApp”，但用户的桌面上已经有一个名为“MyApp”的快捷方式，我希望 Wix 安装快捷方式“MyApp (2)”（或类似的东西）并保持现有的“MyApp”快捷方式不变。

我在 VS 2005 ( .wxs ) 中创建了一个简单的 Wix 3 合并模块

我已经添加了项目“项目”作为对这个合并模块的引用，但是我继续收到这个错误

错误 7 未定义的预处理器变量“$(var.Project.TargetFileName)”。

任何建议，我相信我只是在这里遗漏了明显的东西。

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.

我目前正在使用 WIX，但不断遇到限制（例如将属性扩展为另一个属性的值的能力）。也不确定我是否遇到了 FileSearch 元素的错误，因为它没有按预期工作（找不到肯定存在的文件）。我可以使用内置在 dll 中的自定义操作，但只是想知道是否有更好的方法。