“Visual Studio Setup”项目是否适合不同版本的复杂设置？
该应用程序相当大（> 500,000 行代码）并且正在持续开发中。每 6 到 10 个月发布一个新版本。我们有多个配置文件（INI 和 XML）、注册表项、数据库迁移脚本等。该应用程序正在从Visual Basic 6.0迁移到 .NET。旧的安装程序是用Installshield构建的。对Installshield的反馈是：适应性差，重用性差 - 这就是我们评估“Visual Studio Setup”作为替代方案的原因。
我们考虑的其他产品：
我们不喜欢考虑的解决方案：
不，不，不，不，不适用于 Visual Studio 部署项目。我参加过“大型”项目（15,000 个文件，包含数千个合并模块和数百个 InstallUtil 自定义操作，因为 VDPROJ 几乎不公开任何底层 MSI，例如创建服务）。我可以持续几个小时来讲述它到底有多可怕。
我有一个由四名安装开发人员组成的团队，我们混合使用WiX和InstallShield。我们的典型安装有近 100 个功能、800 个合并模块和 15,000 个文件。我们部署了您能想象到的几乎所有类型的资源，包括链接第三方安装以创建完整的产品或系统。我们能够为十多种产品做到这一点，每个产品都建立在多个集成、发布和维护分支之上。我们四个人支持一个拥有 400 多人、大约 250 名开发人员的组织。
我们能够做到这一点是因为 InstallShield 实际上可以为您提供相当多的重用。您使用产品配置和功能/合并模块来创建文件组和业务逻辑的封装。尽管如此，WiX 还是做得更好（尽管学习起来更加困难，而且我们仍然需要 InstallShield 来解决这里和那里的漏洞），所以我们一直在尽可能地将我们的基线慢慢过渡到 WiX。
不要去那里！！我们认为这对于一些简单的安装程序来说是可行的，但结果却是一场噩梦……乍一看，VS 设置项目看起来不错，但很快你就会意识到各种缺陷 - 这意味着你将编写一个一堆用于完成最简单任务的自定义操作代码（例如，服务处理和安装到定义明确的特殊目录中，这些目录无法从“漂亮的”安装项目 GUI 访问）。
您只能使用一些非常基本的表单来获取用户输入（例如，无法输入密码）。安装程序版本号不会自动增加。文件处理很糟糕——您必须手动选择每个文件。也就是说，您不能只说“将此目录中的所有文件安装到该目录中”——坐下来手动扫描包含数百个文件的目录中的新文件，这是一项了不起的任务。
不，选择 WiX，虽然学习曲线可能看起来比 VS 安装程序稍差 - 但我多次后悔我们没有这样做。