安装科学

Question

我很少接触RPM，机械和WIX。也就是说，我有兴趣制作一个跨平台安装工具(Linux，Windows)来支持我自己产品的升级和降级(versiona和修补程序)。我不认为这是一个可以轻易讨论的话题，我想学习艺术的科学(或科学的艺术)。如果我成功了，并构建了一个非常成功的安装工具，那么它将具有以下特性：

• 不依赖于特定于平台的工具(如Windows安装程序)。
• 读取XML或声明性语法以满足安装要求。
• 尽量减少升级或降级我的产品的步骤(而不是要求完全卸载和重新安装)。
• 不需要了解临时产品版本，以便跳转版本(即可以将我的一个产品从版本1升级到版本3，而不需要通过版本2)。

我确信，实现这一目标的“关键”是将版本视为“点A到点B”问题，这意味着A和B由两个XML "version“文档描述，这些文档包含所有部件和操作的信息(文件，或注册表项等平台细节)。我的安装工具将“加入”或比较这两个文档，并确定将A转换为B的最小更改集。在某种程度上，我相信这正是Windows安装程序所做的。

当然还有更多的复杂性，但这正是这篇文章的重点。关于这个主题的信息“圣经”在哪里？记住，我想让我自己的安装程序-而不是使用特定于平台的。对于那些关心我的人，我的产品通常是用C++或C#写的。

或者我应该学习一些类似水蒸气的东西，它是跨平台的，有“自动的游戏更新”作为其功能的一部分。在我的例子中，在线部署的问题已经得到了解决。这只是我正在检查的最后一个安装步骤。蒸汽是否使用本机安装程序(如MSI)？如果是的话，那不是我要找的。

总之，我应该走什么样的道路，才能在这一课题的科学上有所建树？

Answer 1

我不是专家其他人可以给你更好的答案但是..。

不要以声明的方式列出安装你的产品所需的步骤--你最终会做出假设，这最终会被证明是错误的。相反，您应该考虑定义安装的最终状态，让安装程序担心如何实现这一点。

另一个考虑是，降级可能会带来巨大的复杂性，这取决于您的产品-它是否必须降级数据库模式/文件格式/？简而言之，你的应用程序的每个版本都需要完全向前和向后兼容(或者至少是优雅地失败)。还可以考虑应用程序的V1将设置存储在文件中的场景。V2也加入了更多的设置。您降级为V1 -当更改设置时，它应该做什么？保留V2设置？甩了他们？一些V2设置是否改变了V1设置的影响/含义？这些决定是由你的应用程序还是你的安装程序做出的？

不管怎么说，不管怎么说，我认为你至少需要：

• 一个中央服务器/场，为您的应用程序的每个版本提供完整的文件和一些API/Web服务，它允许安装程序检索文件/文件集/？适当时(您可以将其绑定到像svn这样的源代码管理系统中)
• 某种在环境中指定系统安装后状态的方法--不可知的方式(想想安装路径-- /usr/??? --应该映射到windows上的C:\Users\???或C:\Program Files吗？另外，别忘了它可能是一台64位的机器，所以它可能是C:\Program Files (x86)。
• 一个非常聪明的安装程序，为多个平台编写，尽可能多地重用代码(Java，Mono，？？)

安装程序应该这样做(简单地)：

• 确定所需产品的版本。
• 下载/阅读适当的清单。
• 将所需的情况与当前的情况进行比较(注意:当前本地系统上的是什么，而不是根据当前版本的清单在系统上应该是什么)
• 生成协调这两者的步骤列表，同时考虑到任何依赖项(在复制文件之前不能设置文件权限)。您可以使用校验和/散列/类似的方法将现有文件与所需的文件进行比较，从而只下载实际需要的文件。
• 可能需要完全备份
• 下载/解压缩所需文件。
• 下载/解压缩第三方依赖项-稍后的.Net框架版本/类似
• 尽可能以原子的方式执行安装步骤(至少要记录所采取的步骤，以便可以撤消这些步骤)
• 潜在地应用任何版本跳转特定的更改(向上/向下的db，配置文件等)
• 尽可能多地验证安装(再次校验和)

所有这些都不能解决安装程序本身需要升级时该做什么的问题。

我在Windows上使用的一种技术是，安装程序可执行文件本身只不过是一个带有一些接口的包装器，这些接口在运行时动态加载实际安装程序--因此我可以移动/卸载/重新加载程序集等文件。从一个几乎从未改变过的固定过程中。

正如我上面所说，我绝对不是一个专家，只是一个新手谁已经做了一些自己。我相信你可以从其他人那里得到更完整的答案，但我希望这能帮上一点忙。