是否有构建后可扩展的安装程序系统

时间:2010-05-28 07:21:30

标签: windows-installer modularity

我们有一个产品需要为其创建安装程序。 它有许多组件可以根据情况需要安装或不安装。

当我们发运安装包时,我们希望能够安装包含任意数量的附加组件。

例如,Foo Manager Pro包含:

  • Foo Manager Console
  • Foo Manager数据库
  • Foo Manager Services

这可能会像以下一样发货:

  • FooManagerInstaller.exe
  • FMPConsole.pkg
  • FMPDatabase.pkg
  • FMPServices.pkg

包可能包含以下内容:

  • 清单
  • 要部署的文件
  • 要执行的其他脚本
    (例如,查找文件foo.config,执行一些XML操作)

如果客户想要在安装过程中添加自定义皮肤和一系列插件,他们会创建自己的包:

  • FMPConsoleSkins.pkg
  • ClientWebservices.pkg

如果该客户端随后将其发送给想要添加更多自定义的其他人 - 他们可以以相同的方式执行此操作。

我们可以从头开始构建 - 但是想检查这种安装系统是否已经存在。

我们已经有了一组NAnt脚本,它们做的事情并不太远。但它们难以维护,而且非常复杂。它们不提供我们期望从安装程序中获得的任何“细节”(如跟踪已部署的文件并在安装失败时将其删除)。

我们一直在关注NSIS并使用WiX构建MSI,但目前尚不清楚这些可以为我们提供下游提供额外软件包的能力,而无需发明我们自己的安装程序语言。

2 个答案:

答案 0 :(得分:1)

此响应仅针对Windows Installer(以及WiX);我从来没有机会使用NSIS。

Windows Installer本身并不适合这种可扩展性。如果您想要完全支持弹性(自我修复,广告等),那么下游添加的文件必须添加转换或补丁,并且必须在驾驶室中可用或在源文件系统上未压缩。为了使最终用户无缝安装,引导程序需要识别这些扩展并将其作为安装的一部分应用。但是,如果您希望修补核心安装,那么必须考虑下游补丁的想法是非常复杂的。

如果您不需要Windows Installer的弹性,则可以将各种安装和卸载步骤实现为自定义操作。这些操作可以读取您的自定义pkg格式和清单,并相应地执行操作,至少对于安装。弄清楚如何存储或重新创建卸载信息将是关键。假设您支持每台机器(而不是每用户),这些操作需要延迟(In-Script),因此与安装可用的属性和目录的联系最少 - 如果您想要研究CustomActionData走这条路。 (但请注意;我在搜索中看到的第一个打击是与“Visual Studio中的部署”主题不太相关。)

答案 1 :(得分:0)

我知道许可证可能会花费一些,但是“Installshield”(我测试了限量版感谢vs 2010)有很多关于这些东西的功能,还有关于更新/降级,我不知道是否确实有你的脚步但是测试限量版(仍然是免费的)可能是一个好主意,也许你可以看到你需要的功能。