Visual Studio 安装项目是否适合复杂的设置？

Question

“Visual Studio 安装程序”项目是否适合不同版本中的复杂设置？

该应用程序相当大（> 500,000 行代码）并且正在持续开发中。每 6 到 10 个月就会发布一个新版本。我们有多个配置文件（INI 和 XML）、注册表项、数据库迁移脚本等。该应用程序正在从 视觉基本6.0 到.NET。旧的安装程序是用 安装盾. 。反馈至 安装盾 是：适应性差，重用性差 - 这就是我们评估“Visual Studio 安装程序”作为替代方案的原因。

我们考虑的其他产品：

免费解决方案

• 维克斯
• 国家信息安全局

商业解决方案

• 安装盾 （再次...）
• 明智的
• 高级安装程序
• 是不是少了什么东西？

我们不喜欢考虑的解决方案：

• 创新设置 （就是感觉不太对劲）

Answer 1

对 Visual Studio 部署项目来说，不，不，不，不。我参与过“大型”项目（15,000 个文件，包含数千个合并模块和数百个 InstallUtil 自定义操作，因为 VDPROJ 几乎不公开任何底层 MSI，例如创建服务）。我可以用几个小时来讲述这到底有多么可怕。

我有一个由四名安装开发人员组成的团队，我们混合使用 维克斯 和 安装盾. 。我们的典型安装有近 100 个功能、800 个合并模块和 15,000 个文件。我们部署几乎所有类型的资源，包括链接第三方安装以创建完整的产品或系统。我们能够为十多个产品做到这一点，每个产品都构建了多个集成、发布和维护分支。我们四个人支持一个拥有 400 多人、大约 250 名开发人员的组织。

我们之所以能够做到这一点，是因为 InstallShield 实际上可以为您提供相当多的重用。您可以使用产品配置和功能/合并模块来创建文件组和业务逻辑的封装。尽管如此，WiX 做得更好（尽管学习起来更困难，而且到处都有漏洞，我们仍然需要 InstallShield），所以我们一直在尽可能地将我们的基线慢慢过渡到 WiX。

Answer 2

不要去那里！我们认为这对于一些简单的安装人员来说是可行的，但事实证明这是一场噩梦......乍一看，VS 设置项目看起来不错，但很快您就会意识到各种缺陷 - 这意味着您将编写一堆自定义操作代码来完成最简单的任务（例如，服务处理和安装到定义良好的环境中）无法从“nice”安装项目 GUI 访问的特殊目录）。

您只能使用一些非常基本的表单来获取用户输入（例如不可能输入密码）。安装程序版本号不会自动递增。文件处理很糟糕 - 你必须手动选择每个文件。也就是说，您不能只是说“将此目录中的所有文件安装到该目录中” - 坐下来手动扫描具有数百个文件的目录中的新文件是一项非常棒的任务。

不，选择 WiX，尽管学习曲线可能看起来比 VS 安装程序稍差一些 - 但我多次后悔我们没有这样做。