1

我们决定为我们的部署解决方案创建一个自定义引导程序。我们目前正在重新编写和重新设计我们所有产品的部署策略。可悲的是，我们都不是部署专家。

以下是我们目前所拥有的：

A. MSI 软件包将在 InstallShield 中编写。我们将使用 Installshield 提供的任何功能（IIS 集成、COM 注册、注册表等）。将不会使用 InstallShield 创建的对话框（这就是引导程序的用途）。MSI 将静默安装。

B. 每当我们需要为 InstallShield 无法处理的内容编写 CA 时，我们将使用 DTF 在托管代码 (C#) 中编写它们。我们将创建一个“自定义操作框架”，它将“标准化”我们如何使用自定义操作。

C. 我们将在 C# 中创建一个自定义引导程序（“setup.exe”）来“处理”安装。

我们决定采用多 MSI 方法并使用 MSI 事务从 boostrapper 中“链接”安装（灵感来自 Office 2007 安装程序）

我们设想创建的 boostrapper 的灵感来自 Visual Studio 和 SQL Server 的 bootstrapper。助推器将负责以下工作：

  1. 先决条件安装：每个应用程序都需要一个先决条件。这些先决条件与其他元数据一起列在与 MSI（灵感来自 Office 2007 安装程序）位于同一文件夹中的 XML 文件中。根据系统的当前状态，boostrapper 将决定安装或不安装哪个先决条件。
  2. 功能选择：我们计划以不适合立即向最终用户显示的方式构建“内部”MSI 功能。我们将功能标记为“Core_Files”、“Vista_Only”或“64bit_Only”。根据 XML 文件（第 1 项）和目标系统上的元数据，引导程序将负责“填充”用户可以自定义的“功能树”（也受 Office 2007 引导程序的启发）。
  3. 安装前检查：引导程序将负责检查系统是否准备好接收安装。例如，如果机器需要在安装之前重新启动，或者如果用户需要手动安装服务包、补丁或 Windows 组件。任何需要用户干预的事情都应该在这里显示。将其视为带有检查和 exe 的检查列表（列表框）。（灵感来自 SQL Server 的引导程序）。“规则”将用 C# 编写。
  4. 应用程序配置：对于需要在安装前“配置”的应用程序。这些“参数”（用户配置）将通过MSI Properties传递给相应的 MSI 。
  5. 实际安装：引导程序将执行安装。必要时应遵守适当的“交易”。应该组合在一起的所有“产品”应在添加/删除程序中显示为一个产品（通过弄乱 ARP 条目）。此外，每个正在安装的 MSI 都应报告正确的进度。

——这就是我们目前所拥有的。

我认为有一些开箱即用的解决方案可用于创建自定义引导程序，如 dotNetInstaller 和 BMG。我们已经对其进行了研究，但它并不像我们希望的那样灵活。还有BURN，但我们不确定它是否准备好迎接黄金时段。

所以我们在这里......我们决定创建自己的自定义引导程序。

问题：

我们疯了吗？我们不应该创建自己的引导程序吗？上面列出的哪些想法是不现实的？有更好的方法吗？

任何有关我们情况的意见将不胜感激。另外，如果您有任何问题，请不要犹豫。

4

2 回答 2

2

坦率地说，Burn 至少要一年才能完成。您已经拥有 InstallShield 和 IMO，它拥有目前可用的最好的现成引导程序。我会将您的要求范围缩小并使其适合盒子。如果你学会把它推到极限，我从你那里读到的几乎所有东西都可以使用 InstallShield 完成。

于 2011-01-19T02:30:47.047 回答
1

无论如何，我都会选择 Burn 或一些已经存在的解决方案。

我敢肯定，一段时间后，您将面临您现在无法想象的新问题。如果你面对他们，这意味着 Burn 的开发人员已经面对他们并且可能已经解决了他们。如果没有，Burn 有一个庞大的社区，可以比您更快地修复潜在错误。

专注于您正在开发的软件，而不是编写安装程序/引导程序。

如果我在你的鞋子里，我会试一试。我会找我几天，看看它是否符合我的要求。

于 2011-01-18T23:37:42.963 回答