我发现wix是一个很好的选择（尽管非常陡峭的学习曲线）if您需要在复杂的环境中管理安装程序，因为

• 设置定义以XML格式存储


• 
  
• 很容易集成到您的自动构建


• 部分设置可以是自动生成


• 它允许您定义小的可重用模块并管理它们之间的复杂依赖关系。


• 没有费用或许可问题（之前我们都必须使用一个Installshield PC）

为什么XML格式是一个优点：这允许您充分利用代码版本控制系统，如颠覆或汞。检查变更，检查历史，甚至合并各分支机构之间的变化是一件轻而易举的事情。将其与不透明的二进制blob的installshield项目进行比较。

我通过管理复杂的依赖关系来表示：在我们的例子中，我们有一个大的可重用组件库，它们之间的依赖关系，以及建立在其上的许多应用程序。在wix之前，这是一个噩梦，当某个地方引入了新的依赖：所有设置都必须更新。

现在用wix，我们有一个 ComponentGroup 为每个库，组织成一对夫妇 wixlibs 。每个组件组都使用 ComponentGroupRef 参考其它组件组。应用程序设置开发人员只需要引用直接依赖关系的组件组，并且wix将通过跟随引用来执行其他操作。因此，引入新的依赖关系仅需要进行单一的本地更改。我们的自动化构建和wix完成其余的重新生成所有设置。

Programmers that actually promote their products to production need an installer. (pre-emptive "programming related" justificaton.)

For deploying a new suite of internal corporate apps and services, I'm trying to decide between using WIX and the InstallShield Express edition that comes with Visual Studio 2010.

I've looked, but haven't found a feature matrix that highlights the features that are not in the express edition. I expect WIX to be generally quite capable, but more difficult to use, and have heard of situations that WIX doesn't support well.

Has anyone found a feature matrix, or have other recommendations on the long-term best way to manage internal deployments?

I find that wix is a great choice (in spite of the very very steep learning curve) if you need to manage installers in a complex environment because

• setup definitions are stored in an XML format
• it gives you full control to the underlying windows installer technology; the XML schema typically closely follows the windows installer database schema (which is also the main reason why the learning curve is so steep)
• It is easy to integrate into your automated build
• Parts of the setup can be generated automatically
• It allows you to define small reusable modules and manage complex dependencies between them.
• no cost or licensing issues (before wix we all had to use a single "Installshield PC")

Why the XML format is an advantage: this allows you to fully leverage code versioning systems like subversion or mercurial. Reviewing changes, examining history or even merging changes across branches is a breeze. Compare that to installshield projects which are opaque binary blobs.

What I mean by managing complex dependencies: in our case we have a big pool of reusable component libraries with a complex set of dependencies between them, and many applications that were build on top of that. Before wix, this was a nightmare when a new dependency was introduced somewhere: ALL setups had to be updated.

Now with wix, we have a ComponentGroup for each library, organized into a couple wixlibs. Each component group references other component groups that it depends on with a ComponentGroupRef. Application setup developers only need to reference the component groups of direct dependencies, and wix will do the rest by following the references. As a result, introducing a new dependency only requires making a single local change. Our automated builds and wix do the rest to regenerate all the setups.