【问题标题】:Installer capabilities, WIX vs InstallShield Express安装程序功能,WIX 与 InstallShield Express
【发布时间】:2011-01-13 05:14:39
【问题描述】:

真正将其产品推广到生产环境的程序员需要安装程序。 (先发制人的“编程相关”理由。)

为了部署一套新的内部企业应用程序和服务,我正在尝试在使用 WIX 和 Visual Studio 2010 附带的 InstallShield Express 版本之间做出决定。

我已经查看过,但没有找到一个功能矩阵来突出快速版中没有的功能。我预计 WIX 总体上是相当有能力的,但更难使用,并且听说过 situations that WIX doesn't support well.

是否有人找到了功能矩阵,或者对管理内部部署的长期最佳方式有其他建议?

【问题讨论】:

  • Visual Studio 2010 提供的 InstallShield 版本不是 Express 版,而是限量版:blogs.msdn.com/somasegar/archive/2009/12/14/… 如果您正在尝试 VS2010 测试版,您应该可以尝试 InstallShield Limited Edition 测试版,因为看看它们是否适合您的需求。

标签: deployment visual-studio-2010 installation wix installshield


【解决方案1】:

InstallShield Express 用于基本部署(它只不过是美化的 WinZip)。你也可以查看我最喜欢的AdvancedInstaller。他们也有免费的特快版,但我认为它们对你都没有用,因为如果你需要对 IIS、MS SQL、Active Directory、GAC 等做任何事情,你将需要“企业级”版本。 WiX 是免费的,但学习曲线非常陡峭,不值得学习。后悔学了。

如果您只需要它用于内部部署并且不能在安装程序上花费 1,000 美元,那么只需从头开始创建您自己的“安装”项目。 System.EnterpriseServices.Internal 命名空间包含一些有用的 IIS、GAC 等包装器。System.Configuration.Install.ManagedInstallerClass 可以帮助您部署 Windows 服务。换句话说,您可以从头开始制作自己的程序,该程序可以处理部署主要产品的所有必要步骤。许多公司的旗舰产品不使用商业安装程序,而是自己制作。

【讨论】:

  • 感谢您远离 InstallShield 并指向 .Net 类的自定义安装选项。这可能对我们有帮助。我想我会给 WIX 一个机会,但如果我发现它和你一样麻烦,很高兴知道其他公司在需要时只需制作自己的安装程序。
  • 您不能在安装程序上花费 1000 美元,但您可以“浪费”数周的开发时间(开发人员需要花钱)来构建自己的?
  • @anon2009,这可能令人惊讶,但在大多数公司中,开发人员在自己的安装程序上工作数周比说服管理层购买 1000 美元的工具更容易。此外,每个开发人员通常需要 1000 美元的企业许可证成本,因此在大公司中,构建自己的工具实际上比购买几十个许可证更便宜、更灵活。
  • Lubos,这正是问题所在。经理们不明白,花费一个月的开发时间来构建您可以购买的东西并拥有您的团队将构建的 1000 多个功能是一个错误。所谓失去机会。开发团队应该是公司解决解决方案所需的产品,而不是重新发明轮子。
  • @anon2009,我同意 anon2009 的观点,但可悲的事实是,许多公司对预算进行了如此严格的审查,以至于经理获得开发人员时间比获得 500 美元要容易得多.短视?当然可以,但经理们认为他们正在“削减成本”。
【解决方案2】:

如果您需要在复杂环境中管理安装程序,我发现 wix 是一个不错的选择(尽管学习曲线非常陡峭),因为

  • 设置定义以 XML 格式存储
  • 它使您可以完全控制底层的 Windows 安装程序技术; XML 架构通常紧跟 Windows 安装程序数据库架构(这也是学习曲线如此陡峭的主要原因)
  • 很容易integrate into your automated build
  • 部分设置可以generated automatically
  • 它允许您定义小型可重用模块并管理它们之间的复杂依赖关系。
  • 没有成本或许可问题(在使用 wix 之前,我们都必须使用单个“Installshield PC”)

为什么 XML 格式是一个优势:这允许您充分利用代码版本控制系统,如 subversion 或 mercurial。审查变更、检查历史甚至跨分支合并变更都是轻而易举的事。将其与不透明二进制 blob 的 installshield 项目进行比较。

我的意思是管理复杂的依赖关系:在我们的例子中,我们有一个庞大的可重用组件库,它们之间有一组复杂的依赖关系,许多应用程序都是在此基础上构建的。在 wix 之前,当某个地方引入了新的依赖项时,这是一场噩梦:必须更新所有设置。

现在有了 wix,我们为每个库都有一个 ComponentGroup,并组织成一对 wixlibs。每个组件组使用ComponentGroupRef 引用它所依赖的其他组件组。应用程序设置开发者只需要引用直接依赖的组件组,wix 将按照引用完成其余的工作。因此,引入新的依赖项只需要进行一次本地更改。我们的自动化构建和 wix 会完成其余的工作以重新生成所有设置。

【讨论】:

  • 谢谢,你说服我选择 WIX。我希望我们能像你一样顺利地工作。
  • 任何使用 Wix 的完整示例?
【解决方案3】:

可在此处找到 Install shield 的功能矩阵:

http://www.flexerasoftware.com/products/installshield/features.htm

但是,对于 IIS 部分(我假设您需要基于我之前问题的链接的 IIS)它所说的只是“有限”。您可以猜测 Limited 的含义,但我敢打赌它不会支持企业级部署。

【讨论】:

  • 感谢您找到详细信息。我相信你对这些限制是正确的。他们必须严格限制企业客户需要的东西,以便用企业资金推动客户的销售。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-05-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多