在C＃中创建自定义引导/引导加载程序 [英] Creating a custom bootstrap / bootloader in C#

问题描述

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

这是我们到目前为止：

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的引导程序。 boostrapper将负责以下内容：

1. 先决条件安装：每个应用程序都需要先决条件。这些先决条件列在与MSI（受Office 2007安装程序启发）相同文件夹上的XML文件以及其他元数据中。根据系统的当前状态，boostrapper将决定要安装哪个先决条件。


2. 功能选择：我们正在计划将内部MSI的功能，使其不会立即显示给最终用户。我们将具有标记为Core_Files或Vista_Only或64bit_Only的功能。根据XML文件（项目1）和目标系统上的元数据，引导程序将负责填充用户可以自定义的特征树（也可以从Office 2007引导程序启发）。


3. 安装前检查：引导程序将负责检查系统是否准备好接收安装。例如，如果机器需要在安装之前重新启动，或者用户需要手动安装Service Pack，补丁或Windows组件。这里需要显示需要用户干预的任何事情。将其视为支票和列表的检查列表（列表框）。 （从SQL服务器的引导程序启发）。 规则将以C＃编写。


4. 应用程序配置：对于在安装之前需要配置的应用程序。这些参数（用户配置）将通过MSI属性传递到相应的MSI。


5. 实际安装：引导程序将然后执行安装。必要时应遵守适当的交易。应该组合在一起的所有产品应在添加/删除程序中显示为一个产品（通过混淆ARP条目）。另外，正在安装的每个MSI都会报告正确的进度。

- 这是我们到目前为止。 b
$ b

我认为有几个开箱即用的解决方案可以创建像dotNetInstaller和BMG这样的自定义引导程序。我们已经研究了它，但并不像我们所希望的那么灵活。还有BURN，但是我们不知道是否准备好黄金时段。

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

问题：

我们疯了吗？我们不应该创建自己的bootstrapper？上面列出的想法是不现实的？有更好的方法吗？

对于我们的情况的任何输入将不胜感激。此外，如果您有任何问题，请随时问。

解决方案

坦白说，Burn不会做了至少一年。您已经拥有InstallShield和IMO，它具有当前可用的最好的现成引导程序。我会把你的要求放在一起，使其适合盒子。几乎所有我读过的内容都可以使用InstallShield来完成，如果你学会把它推到极限。

We've decided to create a custom bootstrapper for our deployment solution. We are currently re-writing and re-designing our deployment strategy for all of our products. Sadly, none of us are deployment experts.

Here's what we have so far:

A. The MSI packages will be authored in InstallShield. We will use whatever feature Installshield offers (IIS integration, COM registration, Registry, etc). The dialog's created by InstallShield will not be used (that is what the bootstrapper is for). The MSIs will be installed silently.

B. Whenever we need to write CA's for stuff that InstallShield can't handle, we will be writing them in managed code (C#) using DTF. We will be creating a "Custom Action Framework" that will "standardize" how we use custom actions.

C. We will create a custom bootstrapper (the "setup.exe") in C# to "handle" the installation.

We have decided to go with a multiple MSI approach and use MSI transaction to "chain" the installation from the boostrapper (inspired from Office 2007 installer)

The boostrapper that we are envisioning to create is inspired from Visual Studio's and SQL Server's bootstrapper. The boostrapper will be responsible for the following:

1. Prerequisite installation: Each application require a pre-requisite. These pre-requisites are listed in an XML file placed on the same folder as the MSI (inspired from Office 2007 installer) along with other metadata. Depending on current state of the system, the boostrapper will decide which pre-requisite to be installed or not.
2. Feature selection: We are planning to structure the "internal" MSI's feature in such a way that it will not be appropriate to be displayed right away to the end-user. We will have feature labeled as "Core_Files", or "Vista_Only" or "64bit_Only". Depending on the metadata on the XML file (on item 1) and the target system, the bootstrapper will be responsible in "populating" a "feature tree" that the user can customize (also inspired from Office 2007 bootstrapper).
3. Pre-installation Checks: The bootstrapper will be responsible in checking if the system is ready to receive the installation. For instance, if a machine needs to reboot prior to installation or if the user needs to manually install a service pack, patch or a windows component. Anything that needs to be done that needs user intervention should be displayed here. Think of it as a check list (a listbox) with checks and exes. (Inspired from SQL server's bootstrapper). The "rules" will be written in C#.
4. Application Configuration: For application that needs to be "configured" prior to installation. These "parameters" (user configuration) will be passed to the respective MSI via MSI Properties.
5. Actual Installation: The bootstrapper will then perform the installation. Proper "transaction" should be observed when necessary. All "products" that should be grouped together shall be displayed as one product in Add/Remove Programs (by messing with the ARP entries). Also, proper progress shall be reported by each MSI being installed.

-- That's what we have so far.

I think there are a couple of out-of-the-box solutions for creating a custom bootstrapper like dotNetInstaller and BMG. We've look into it but it's not as flexible as we've hoped. There's also BURN but we're not sure if it's ready for primetime.

So here we are... we've decided to create our own custom bootstrapper.

Question:

Are we crazy? Shouldn't we be creating our own bootstrapper? Which ideas listed above are not realistic? Is there a better approach?

Any input regarding our situation will be greatly appreciated. Also, if you have any questions, please don't hesitate to ask.

解决方案

Frankly, Burn isn't going to be done for at least a year. You already have InstallShield and IMO it has the best off the shelf bootstrapper currently available. I'd scope your requirements back and make it fit the box. Pretty much everything I read from you can be done using InstallShield if you learn to push it to it's limits.

这篇关于在C＃中创建自定义引导/引导加载程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！