我很惊讶没有人提到在构建期间使用T4生成WXS文件。我是通过Henry Lee @ New Age Solutions了解到这一点的。

实际上，您创建了一个自定义MSBuild任务来执行T4模板，该模板在编译Wix项目之前输出WXS。这允许您(取决于您如何实现它)自动包含来自编译另一个解决方案的所有程序集输出(这意味着您不再需要在添加新程序集时编辑wxs)。

我们将产品版本显示在GUI的第一个屏幕的某个位置(很小)。因为人们每次都倾向于在选择正确版本时犯错误。(这让我们开发人员找了很长时间。) 我们已经设置了TFSBuild来生成转换(。MST文件)为我们不同的环境配置。(我们知道需要部署到的所有环境)。

由于Grant Holliday的原始博客帖子已经关闭，我复制粘贴了它的内容:

MSBuild任务从xml3月11日2008生成MSI转换文件

在我之前的文章中，我描述了如何使用MSI Transform (*.mst)文件将特定于环境的配置设置从通用MSI包中分离出来。

尽管这为您的配置提供了一定程度的灵活性，但Transform文件有两个缺点:

它们是二进制格式的 您不能“编辑”或“查看”转换文件。您必须应用它或重新创建它，以查看它包含哪些更改。

幸运的是，我们可以使用Microsoft Windows安装程序对象库(c:windowssystem32msi.dll)打开MSI“数据库”并创建转换文件。

感谢Alex Shevchuk -从MSI到WiX -第7部分-使用转换自定义安装，向我们展示如何用VbScript实现这一点。基本上，我所做的就是以Alex为例，使用Interop.WindowsInstaller.dll实现了一个MSBuild任务。 MSBuild任务

下载源代码和示例transforms.xml (~7Kb压缩VS2008解决方案)

创建一个具有自定义操作的UI，该操作将设置一个变量，并且UI将根据自定义操作中设置的变量禁用/启用下一个按钮(或类似的)。

不像你想的那么简单，也不是太难，只是没有任何文档!

Wix与条件，属性和自定义操作的交互

从Wix3.0及更高版本打印EULA

1)当你编译你的wix源代码时，light.exe必须在命令行引用WixUIExtension.dll。为此使用命令行开关-ext。

2)如果当你在WixUIExtension.dll中添加引用时，你的项目编译失败，这很可能是因为对话框id的冲突，即你的项目使用了与WixUIExtension.dll中一些标准对话框相同的对话框id，给你的对话框提供不同的id。这是一个很普遍的问题。

3)你的许可对话框必须有id为“LicenseText”的ScrollableText控件。Wix在打印时搜索该控件的名称。

<Control Id="LicenseText" Type="ScrollableText" X="20" Y="60" Width="330" Height="160" Sunken="yes" TabSkip="no">
    <Text SourceFile="License.rtf" />
</Control>

以及指向自定义动作的PushButton

<Control Type="PushButton" Id="PrintButton" Width="57" Height="17" X="19" Y="244" Text="Print">
    <Publish Event="DoAction" Value="PrintEula">1</Publish>
</Control>

4)使用Id="PrintEula"定义CustomAction，如下所示:

<CustomAction Id="PrintEula" BinaryKey="WixUIWixca" DllEntry="PrintEula" Return="ignore" Execute="immediate" />

注意:BinaryKey在Wix3.0和Wix2.0中是不同的，必须准确地为“WixUIWixca”(区分大小写)。

当用户按下按钮时，他/她将出现标准的选择打印机对话框，并能够从那里打印。

使用RobM特殊的“记住属性”模式

http://robmensching.com/blog/posts/2010/5/2/The-WiX-toolsets-Remember-Property-pattern

奇妙的问题。我希望看到一些最佳实践的展示。

我有很多要分发的文件，所以我将项目设置为几个wxs源文件。

我有一个顶级源文件，我称之为产品。WXS，它主要包含用于安装的结构，但不包含实际的组件。这个文件有几个部分:

<Product ...>
  <Package ...>
    <Media>... 
   <Condition>s ...
   <Upgrade ..>
   <Directory> 
        ...
   </Directory>
   <Feature>
      <ComponentGroupRef ... > A bunch of these that
   </Feature>
   <UI ...>
   <Property...>
   <Custom Actions...>
   <Install Sequences....
  </Package>
</Product>

其余的.wix文件由包含在Product.wxs的Feature标签中引用的componentgroup的片段组成。我的项目包含我分发的文件的一个很好的逻辑分组

<Fragment>
   <ComponentGroup>
     <ComponentRef>
     ....
    </ComponentGroup>
    <DirectoryRef>
      <Component... for each file
      .... 
    </DirectoryRef>
</Fragment>

这并不完美，我的OO蜘蛛感觉有点刺痛，因为片段必须引用产品中的名称。wxs文件(例如DirectoryRef)，但我发现维护一个大的源文件更容易。

我很想听到关于这一点的评论，或者如果有人有任何好的建议!