现代复杂Windows软件安装过程？

Question

我们正试图重新思考我们软件套件的安装过程，我试图找出我们面临的具体缺陷，而不用我们/我的有限镜头来观察今天的Windows软件环境。

我们已经收集了一组我们软件的安装可能需要处理的问题，我想收集这些要点是否有意义在Windows安装过程中考虑，或者这些点中的一些点是否最好放在安装过程的上下文之外。

至少对于应用程序套件的一个子集，我们面临的问题是至少执行以下操作：

• 要求在机器上运行第三方DMBS
• 预安装.NET框架或vcredist或其他系统范围的资源
• 将文件放入SystemDrive:\Program Files
• (可选)自动更新( Program Files，.)当启动一些应用程序时
• 将图标放入开始菜单/桌面
• 安装和维护Windows服务
• 编辑属于我们软件的注册表项(即HKLM\SOFTWARE\OurShpo\...)
• “安装”应适用于Windows 7和所有版本，包括服务器和LTSB
• “安装”应该是可选的自动化/没有用户交互。

在什么以及如何将这些东西放入安装过程/或安装工具方面有什么最佳实践吗？哪些部分可以完全保持不动，哪些部分可以在应用程序中更好地实现。(例如，文件扩展名关联是一个问题，我很不确定谁的工作是解决这个问题。)

免责声明:我对工具链本身不感兴趣。我知道有InnoSetup，WiX，NSIS .所有这些都能在某种程度上达到--或全部--这些点。问题在于，在不同的Windows版本中，这些点中的哪一点会引发哪些(概念性的)问题，或者在我们的安装过程中，哪些点实际上是没有意义的。

Answer 1

根据我十多年的Windows产品开发经验，如果您想让不得不安装软件的管理员轻松的话，我建议将上面的几乎所有内容都放在基于MSI的安装程序中。这肯定包括“文件扩展名关联”(在某些环境中可能需要管理权限，因此在应用程序中实现这一点并不是一个好主意)。

对于.NET框架或vcredist安装，微软提供现成的安装包，您可以随软件一起分发并嵌入到自己的安装程序中。

对于第三方软件(如DBMS )，它实际上取决于特定的系统、许可条款、供应商提供的内容以及您需要的自定义。如果您在安装应用程序的机器上提供中央服务器安装，或者只是本地DB安装，这也会产生很大的影响。但是所有主要的DBMS供应商都为部署提供了文档，所以您最好检查一下这些文档。

您的目标应该是自动化大多数安装步骤。对于我们的系统，多年来，每当我们看到手动配置步骤时，我们都会问自己

• “有机会让安装程序自动完成吗？”
• “如果没有，是否有机会减少程序出错的可能性，也许是半自动的？”

例如，安装程序通常可以在注册表中检查系统上已经安装了哪些其他必需的组件，或者在哪些位置安装了这些组件，或者它们有哪些版本，这对于实现自动化通常是至关重要的。另一种办法可以是纯粹为行政目的提供某些工具。例如，脚本或GUI工具，用于启动、停止和验证某些windows服务，而不必学习神秘的命令行参数。

关于"Windows版本“：如果您不需要在不同的Windows版本上使用不同的安装过程，并且尝试开发您的应用程序版本--不可知论，那当然更好。但是，如果您有第三方组件要安装，您并不总是拥有对它的完全控制，如果您不能避免这样的步骤，安装程序可以检查版本，并采取不同的行动。

您应该在应用程序中实现的是对依赖项或配置文件条目进行一些验证，并在发生故障时清除错误消息。当有人在安装期间或之后不小心配置系统时，人们不应该猜测周围的情况。尽量找出这些问题的根源。显示(或至少日志)某个文件丢失或格式错误，哪些配置条目格式错误，或者哪个第三方组件没有您预期的版本。

您应该了解的一件事是DB模式升级。对于本地DB，应用程序可以在需要时自动进行架构升级。但是，在中央DB服务器上，这种升级可能需要一个单独的升级安装程序包，以及如何安装它的说明，这可能包括在一定时间间隔内使DB脱机。如果应用程序需要某个模式版本，它应该在程序启动时检查是否安装了该版本，如果没有，则显示一个明确的错误消息。不要只显示像“有什么问题，问管理员”这样的智障文本。相反，显示(或记录)类似“错误检测到，连接的数据库有23.45版本，但应用程序至少需要24.00版本-请询问管理员。”即使用户不能直接使用这些信息，他们也可以将信息发送到支持热线，从而向工作人员提供所需的信息，说明出了什么问题。