我最近不得不努力解决一个安装项目（使用最流行的产品来创建安装：InstallShield），使其适用于产品升级（从一个版本迁移到另一个版本）。最后我发现我需要使用一个长包代码但是正在使用其他一些代码。浪费了我8个小时（测试和调试安装程序很痛苦）。
现在，如果我考虑一下，一旦你完成了编码的所有困难部分，你想要的只是正确的应用程序，库被复制到目标计算机，用户只需运行它。期。这个看似简单的任务通常是一个棘手的任务，“关闭以完成约会”会更加困难。
难道您不认为部署产品在Windows上应该更加困难吗？ （或者安装人员真的应该得到那么多关注，而我只是为此而疯狂？）
您是否曾使用过更简单的部署方案，例如“将文件夹复制到您喜欢的位置并运行exe。当您要删除它时，只需删除该文件夹！”？是否有效并使事情变得更简单？
答案 0 :(得分：7)
痛苦，因为您需要与Windows安装程序搏斗，以造福您的客户。否则你需要做更多的工作
解决所有这些问题的自定义脚本最终会成为比安装本身更大的问题！
我建议您查看Wix。这不完全是孩子的游戏，但它完成了工作。如果您将Votive安装为视觉工作室添加，您将获得intellisense以帮助您正确地构建标签。使用帮助文件，您可以创建非常实用的灵活安装
答案 1 :(得分：4)
我认为你不会在这里看到太多的分歧，特别是关于MSI。我想要记住的一件事是观察许多程序目前使用MSI文件的方式。由于Windows Installer的设计方式，显示UI对话框并使用MSI进行复杂的配置选择非常弱，所以我注意到很多程序被拆分成一堆婴儿MSI，这些MSI通过最小的UI安装父安装程序。 SQL Server 2008安装向导执行此操作。 UPS WorldShip就是这样做的。而且Paint.NET也是这样做的 - 你看到的向导是一个Windows窗体应用程序，它自己启动msiexec（你可以在白色向导窗口的顶部看到Windows Installer的最小UI） ，将任何配置参数作为属性参数传递给msiexec。
出现这种情况的常见情况是，有人负责为同时具有服务器和客户端对应程序的应用程序构建安装程序。如果用户选择服务器选项，则他们可能希望安装新数据库，也可能不希望安装新数据库，这意味着安装SQL Server。但是，当您处于自己的安装过程中时，不能只安装SQL Server，因为Windows Installer不允许您这样做。因此，一个经常的解决方案是编写一个显示向导的应用程序，该向导允许用户配置所有设置选项，然后您的应用程序根据需要启动SQL Server，服务器应用程序和客户端应用程序中的MSI文件。 UI模式;基本上，完全避开Windows Installer的“功能”方面并将其移至MSI级别。 4.5的多包装安装似乎是朝这个方向迈进了一步。如果您还需要在安装过程中从第三方循环非MSI安装程序，例如为某些奇怪的销售点打印机安装打印机驱动程序，这种格式也特别有用。
我也同意Windows Installer缺乏对常见部署方案的内置支持。这意味着当安装不是XCOPY时，他们似乎错过了安装通常不只是“文件+快捷方式+注册表项”的事实。没有用于设置IIS网站，注册证书，创建和更新数据库，向GAC添加程序集等的内置操作。我猜他们认为其中一些应该在首次运行时发生，而不是作为安装的事务部分。在十年的大部分时间里，免费提供的工具和文档非常糟糕 - 非常糟糕。这两个问题都在很大程度上通过WiX项目和DTF（最终使用托管代码自定义操作）来解决，这就是为什么我们都非常感谢Rob Mensching和其他人在该项目上的工作。
我有同样的经历。当你走下“哦上帝，我想我必须成为这个的专家时，安装可以很快吸收你的时间。”我认为最好在项目早期解决它并将其作为构建过程的一部分进行维护。这样，您可以帮助避免开发实际上可卸载的产品的情况。 （Trac就是这方面的一个例子，需要追踪奇怪的Python库的特定版本。）
（我可以继续谈谈Windows Installer有时会决定使用我的慢速外部USB硬盘驱动器作为解压缩文件的地方，在有多少计算机的计算机上，它似乎无所事事。 MSI安装在他们身上，以及这个进度条在单次安装过程中如何重置自己的数十倍是我见过的最愚蠢的事情，但我会将这些咆哮保存一天。=）
我的两分钱;请注意，我真的对Windows安装程序做了足够多的了解，但这是我的评估来自一个小企业开发人员，只是试图使用它。祝你好运！
答案 2 :(得分：3)
如果您首先构建安装程序，使其成为构建系统的一部分，并让它随您的项目一起成长，那么它会更容易。
我同意，Windows安装程序让我疯了。但是有很多情况下xcopy无法解决。有时您希望为多个用户安装，而不仅仅是当前用户。有时您必须注册COM对象。有时您必须对系统进行一系列更改，例如注册服务以在启动时运行，连接到网络服务器等。有时，您的用户无法使用命令提示符。当事情在中途失败时，你总是希望能够将整个事情发挥作用。
整个MSI数据库是否采用最佳方式？我不确定。我是否愿意将钉子钉入我的脑袋而不是写另一行WiX代码？大概。但你不得不承认，它做了你想做的一切。当它没有时，总会有CustomAction选项。
真的，我想看到的是更好的文档（真的，什么是50型动作？给它命名怎么样？）以及更容易篡改的模板。
WiX用户组别名可以很好地回答问题。
你应该阅读RobMen的blog。他做得很好，解释了为什么事情就是这样。关于设置问题，他做了很多思考（比任何人都要多）。
答案 3 :(得分：2)
您是否看过NSIS：http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System？
1：是的，2：没有
答案 4 :(得分：2)
就个人而言，我大多同意@Conrad和@John Saunders。我很久以前就在old blog上写过这个话题。我认为@jeffamaphone有一点关于Windows Installer的复杂性（以及我对安装的过度关注），但我相信Windows Installer仍然是Windows上安装的最佳选择。
答案 5 :(得分：1)
“一旦你完成了所有困难的编码工作”，如果你的所有辛苦工作都没有安装，你就没有做过。安装人员需要每晚每晚建造和测试，几乎从第一天开始。您需要测试是否可以构建和运行安装程序，并且需要验证安装。
否则，谁关心你已经完成了多少辛苦的编码 - 没有人会看到你的工作，如果它没有安装！
请注意，这也适用于XCOPY。
另一件事：如果他们没有测试安装程序安装的内容，那么您的QA测试是什么？你必须测试客户会得到什么！
答案 6 :(得分：0)
正是您所说的原因，我们已经完成了内部版本，由开发团队通过复制所需文件来处理，然后使用脚本和我们自己的实用程序完成其余的设置。
但是，对于最终用户，您必须拥有某种手持向导，我已经在VS中使用了MS安装程序，并发现它令人困惑和笨拙。在那次经历之后，我通过让别人去做安装步骤来避免痛苦。任何人都可以推荐一个好的.Net安装程序吗？
答案 7 :(得分：0)
我使用Installshield，如果你不想做任何太花哨的事情（我为什么会这样）那么它非常简单 - 设置初始设置，选择文件，设置快捷方式并创建setup.exe。
我在代码中处理的所有未来更新 - 对用户来说更方便