什么安装产品使用? InstallShield,WiX,Wise,Advanced Installer等

我目前正在做一些调查,closures我们目前使用的安装包(Wise Installer 9),并转向处理Windows Vista,Windows 7和64位系统的东西。 安装人员的本地化将是有益的,因为我们也有一些法国加拿大客户。

我们目前在以下技术中安装软件包和实用程序:

  • 进展4GL
  • Visual Studio 2005
  • Visual Studio 2008
  • .NET Compact Framework 3.5

我已经看了WiX和InstallShield , Altiris也replace了旧的Wise系统。

我还没有使用过InstallShield,但是从我看到/安装的所有东西中,似乎都是最受欢迎的产品之一。 我浏览了一些与InstallShield有关的Stack Overflow标签,我很好奇这个组织对此有何评论。

我只是默认去他们? 在非.NET的东西的WiX有多好?

我曾在软件开发方面担任过发行经理build筑工程师设置开发人员应用软件包工程师 ,大型企业的SOE工程师部署工程师 (SCCM)。

一路上,我使用了大多数主要的打包工具(一些在许多不同版本中): InstallShield 明智的 (不幸的是,不在市场上), WiX高级安装程序 (只是testing), Orca和我已经testing了一些其他工具 (从http://www.installsite.org链接到;“Windows Installer开发者编写工具 ” – 一个相当详尽的清单的工具)。 我还使用了不太常见的打包和部署工具,例如Computer Associates Unicenter – 现在可能已经不在市场了。

这篇文章概述了一些不同的创作工具的优点以及一些需要注意的问题 。 尽pipe他们有相似之处,但这些工具实际上是完全不同的。 所有的尝试都是为了尽可能客观地描述 – 用积极的和消极的描述现实世界的经验。


相关的部署主题

  • 在深入研究不同工具的评论之前,以下是一些有关MSI技术本身信息的链接。
  • 以下是部署工具中通常支持的部署任务的一般描述 ,以及为什么部署似乎变得越来越复杂。
  • 许多人似乎认为MSI比它值得的更麻烦,有时这是可以理解的。 好处是真实的 – 特别是对企业部署,但也有一些问题。
    • 以下是我写的有关MSI的主要企业收益 (来自serverfault.com)的描述。 文章增长太多,但希望仍然相关。
    • 在同一篇文章中,我写了关于MSI文件中典型的真实世界devise缺陷的文章(这是一个正在进行的工作 – 只是体验“软件双方”的一个“内存转储”:开发和部署)。

的InstallShield

  • function丰富。
  • 随时掌握最新的技术。
  • (设置)面向开发人员。
    • 不同的版本可用。
    • 旗舰产品AdminStudio提供了面向安装开发人员的工具以及面向重新打包的工具。
  • 非常好的发布pipe理本地化自动化function用于构buildstream程自动化。 至less比竞争对手好。
    • 对于复杂的产品来说,发布pipe理可能是InstallShield的主要卖点。 您可以轻松传递各种风格:语言版本,oem版本,查看器,应用程序版本等…使用发布标志和类似的结构。
    • 发布标志主要用于有条件地排除或包含产品的某些部分从每个编译的设置 – 这往往是什么时候做专业家庭的设置要求的很大一部分。
    • Installshield中的版本视图允许您全面了解所有不同的安装types和版本。 您可以看到为Web(一个大型安装文件)或可再分发介质(外部源文件)以及您提供的其他任何口味提供的所有语言版本和发布设置。
      • 至关重要的是,对于每个版本和版本,您可以覆盖重要的设置,例如产品名称,产品版本,软件包产品和升级代码以及必须根据产品版本和语言版本dynamic更改的其他必需设置。
      • 在许多其他产品中,这种types的版本和版本pipe理可能难以实施。 对于更简单的设置,这种types的灵活性可能不那么重要。
    • 产品的自动化API使其可以轻松地从各种types的构build自动化脚本远程控制 ”。
      • 还有命令行构build模块 (用于专用构build服务器)。
      • 使用常规的VBScript / VBA / Javascript自动化,可以轻松实现全套产品和版本的全面自动化。
    • 用于支持不同安装语言的string表的 全面本地化支持
      • 基础对话框还提供了多种语言的现成(额外成本)。
      • 您只需要本地化您自己的设置内容(function列表标题,任何自定义对话框或消息框,带有文本的图像等等) – 仍然很多工作。
      • 您可以提供一个巨大的多语言设置。 由于以下原因 ,我不build议这样做(阅读本地化部分)。 最糟糕的问题是您必须在所有语言中本地化所有新的和已更改的内容,然后才能提供英文版本。 这几乎是不可接受的营销/销售。 而且总是有一些修复需要你重新编译和重新发布一种语言,然后你想在没有UAT和QA的情况下为所有其他语言进行修改。 为每种语言提供单独的构build(更容易实现)更好。
  • 良好的社区支持: 用户社区论坛
  • 相当不错的graphics用户界面,普通的东西相当容易。
  • 全面的MSI-GUI编辑器。
    • 很强大。 有点复杂。
    • 底层MSI技术的GUIfunction的局限性导致了一些障碍和令人讨厌的限制,但是对于所有的部署工具来说都是一样的。
    • 根本原因在于MSI GUI是使用MSI文件本身内的数据表实现的,与Win32对话框的完整“事件模型”相比,这会对对话事件造成严重的限制。
  • function齐全的C风格的脚本语言称为“ Installscript ”自定义操作。
    • Installscript现在编译为本机 – 或者用自己的沙箱模拟,不知道是哪一个。 不需要像以前那样安装运行时
    • 顺便说一句,这个运行时间是一些由于运行时间损坏而引起的相当麻烦的部署问题的源头 – 看起来经常与DCOM相关 – 以及不同运行时版本之间的各种不兼容 。 以下是一些“传统用途”的疑难解答链接:
      • 无法安装InstallShield脚本运行时 。
      • 安装程序无法find或更新ISScript.msi 。
      • Flexera Consumer Central (针对最终用户设置问题)。
    • 虽然运行时是一个非常有问题的错误来源,但自从Installshield 12和更高版本以来 ,所有相关的问题现在似乎都已经被彻底解决了
  • 在GUI中提供了很好的集成帮助
    • 对于这样一个困难的技术非常重要。
    • 通常非常有帮助 – 特别是处理常见任务。
  • 默认的二进制文件存储格式不允许真正的源代码控制或分支(不像WiX开箱即用)。 我认为有一种方法来存储项目的文本格式,但我从来没有使用过。 不知道这将是多么有效。
  • 毫无疑问,迄今为止,所有安装产品都是最脆弱的。
    • 公平地说,大多数错误都与特殊的“ Installscript MSI ”项目types相关,该types为MSI设置(而不是本机,基于表格的GUI被禁止)实现了自定义对话框模型。
    • 换句话说,在任何情况下都不能使用Installscript MSI项目types。 请记住这一点,如果你仍然使用它们 – 它们特别难以正确升级(第一次部署可能没问题,但是升级正在中断)。 其他项目types似乎运作良好。
    • 在放弃了Installscript MSI之后(大多数人似乎都这么做),这个工具对我个人来说工作得非常好(不过没有bug)。
  • 我对支持部署IIS站点COM +应用程序感到不满意。 我需要为WiX的灵活性和可定制性,而不是Installshield的易用性。 没有足够的灵活性和可用的控制。
  • 支持Microsoft App-V虚拟软件包和新的虚拟化技术。
    • 与普通应用程序相比,允许一些新事物。
    • 应用程序stream – 机器上没有本地安装 – JIT。
    • 在同一台计算机上使用两个不兼容的软件。
    • 通过服务器更新。
    • 控制许可 – 同时使用最多的用户或将软件绑定到组/用户。
    • 快速,方便地向用户提供应用程序。
    • 这里有更多微软营销 。

明智的

智者已经正式退休 ,但之前已经复活了。 不幸的是, 一些法律问题可能已经使这个决定了 – 就我所知。 对于这样一个伟大的工具,这将是一个耻辱。 它被Altiris和赛门铁克收购。 现在看来是在市场之外 。 我仍然留在Wise特色的总结中:

  • 快速,简单,function丰富。
    • 整体使用非常好用,function优秀。
    • 缺乏一些(非常)先进的function,如IIS,高级版本pipe理等…
  • 面向pipe理员/重新包装。
    • 比Installshield关注的代码更less。
    • 独特的function和灵活的graphics脚本编辑器。
    • 精心devise的安assembly置GUI。
  • 对于寻求快速而相对简单的方式来部署应用程序的小型开发团队来说 ,这也非常出色。
  • 有时会比最新的技术略有落后(与Installshield相比),但是比较“无bug”。
  • 直观的graphics用户界面,常见的事情是(非常)容易。
  • 在脚本样式编辑器中处理安装顺序configuration和自定义操作非常好。 更多的GUI脚本,更less的编码。
  • 坚如磐石 ,很less有重大的错误。
  • 帮助资源和社区支持不等于InstallShield,但仍然不错。
  • 我的selectdebugging和原型 (快速,稳定,易于使用,伟大的差异function)的工具。
  • 关于差异function(允许两个MSI文件的二进制比较)。
    • 没有其他工具,我已经尝试接近明智的差异的MSI文件的二进制差异。
    • 差异查看器的易用性和清晰度不亚于梦幻般的。
    • 对于企业打包,这种差异function可能是工作中非常关键的一部分,因为您有数百甚至数千个不同的软件包可以pipe理许多不同的版本。
  • 主观上说 :我最喜欢的包装工具。 很可靠。
    • 这是一个真正的耻辱,该工具不再可用。
    • 我们总是希望有一个“轮回”(我已经看到在其他工具中看起来像Wise的GUI片段)。

维克斯

  • 最重要的是文本源文件 。 没有必要将源代码存储为二进制文件,在这种情况下几乎不可能跟踪更改并进行适当的版本控制。
    • 正确的文本来源使开发团队在分支版本合并方面发挥了重要作用。 这是一个巨大的飞跃(在我看来,尤其是对于大公司内部开发而言,stream程非常复杂,周转迅速,开发人员众多)。
    • 对文本源文件的需求和使用是创buildWiX工具包的核心。 这是一个快速和不完整的“WiX的历史”与更多的细节。 推荐阅读,以掌握WiX的基础和理由。
    • 一些将安装程序存储为二进制文件的部署工具可能会在二进制源显示不可能正确跟踪的神秘问题的情况下结束。
      • 特别是在工具更新之后,它也更新了源代码中的格式(无论出于何种原因)。
      • 升级往往会影响到数十个表格和数百个logging,使得有效地追踪真实问题成为不可能的任务。
      • 症状包括诸如突然开始的缓慢构build,突然慢的安装速度,无法解释的编译错误,甚至是整个文件损坏等等。
      • 使用WiX,您可以获得充分的透明度和“精益”。 它只是更干净,更可靠的做到正确和自动更新的源是可能的,但不会导致通过数十个MSI表的级联变化。 结合源代码控制的变化很容易跟踪和(希望)理解 – 没有神秘的,没有logging的东西添加。
      • 尽pipe如此,必须指出的是,从WiX 3升级到WiX 4源文件似乎不是微不足道的。 我们希望这是一次性的情况。 我不知道为什么这件事是诚实的,我没有最新的信息。
      • 也许从Rob Mensching的博客直接查看真实的新闻: http: //robmensching.com/blog/和Bob Arnson的博客https://www.joyofsetup.com/ 。 当互联网变得可能的时候,直接从马的嘴巴 – 这是一个奇妙的世界有时;-)。 有传言说,他们正在做“ 一路下来的乌龟 ”。
  • 坚如磐石,很less有重大的错误
    • 对于那些与其他工具中长期存在的,间歇性的,无法解释的错误而奋斗的人来说,这是一个天赐之物。 {战争故事删除}。
    • 甚至更好:在WiX中,问题实际上似乎得到了修复,有时还有社区的帮助 – 这对于开源工具包是适当的。 大多数时候,核心团队似乎都会照顾它。
  • function非常丰富 ,但有时难以使用。
    • 花时间去习惯,即使习惯了,事情也会变得很“错综复杂”,尤其是如果你没有正确使用包含的辅助工具。
    • 它有助于使用dark.exe反编译工具将现有的MSI文件反编译为WiX XML。 这使您可以在事先不太了解的情况下学习WiX源代码。
    • IISCOM +SQL Server权限防火墙规则等等复杂的事情提供了特殊的可定制性 …“一切”都是可能的,但有时也会有所涉及。
    • WiX有效地“ 扩展Windows安装程序 ”与新的和非常需要的function。 对于那些以前不得不“滚动自己的”解决scheme的人来说,这是一个巨大的好处 – 通常是那些看似微不足道(但仍然非常容易出错)的事情。
    • 这些扩展的力量不能被夸大。 您可以摆脱很多自行编写的,复杂的自定义操作,而采用经过testing的解决scheme 。 有了适当的回滚支持 ! (在供应商设置中一个很被忽视的特征 – 根据我的经验,几乎所有这些特征 – 在中止设置之后导致不清楚的系统状态)。
    • 我有个人经验编写C + + dll与常规任务的自定义操作与适当的回滚支持,工作量是惊人的 – 尤其是实际的回滚function的QA。
  • GUI工具非常less,很less有好的样本可用,特别是对于WiX 4。
    • 事情似乎正在改善, 也许尝试这个简短的总结
    • 一个有趣的项目可能是IsWiX 。 这是值得检查,如果你是一个Visual Studio用户。
    • 我已经过时了,如果你有更多的最新信息,请帮助更新
  • 使用IntelliSense在Visual Studio中完全集成。
    • 显然WiX 4将会支持哪些版本的Visual Studio。
    • 我还没有详细信息,但是您需要最新版本的Visual Studio。 我认为Rob和Bob有很好的博客文章。
  • 它是免费的 (!)。 每个开发者都可以build立这个设置 有人必须拥有它(!)。 真的;-)。
  • 它也是开源的
    • “社区”: https : //github.com/wixtoolset 。 和公开的问题: https : //github.com/wixtoolset/issues/issues
    • 工具包下载也包括DTF( 部署工具基础 )。 .NET类用自动处理所有MSI文件。 在这里看到一个内联示例 。 非常有用,质量好。 没有COM互通来处理。 看到这个serverfault.compost 。 还有Chris Painter的博客 。
  • 你如何开始?
    • 对于基于示例的修改器,请 尝试使用“代码项目”文章 ,快速了解如何使用WiX(WiX 3)创buildMSI文件。 这真的很简单(如果你知道MSI是不言而喻的)。
    • 您也可以阅读这篇WiX Stack Overflow文章以获取更多快速入门提示。
    • 您可以使用WiX的dark.exe(MSI反编译器)将现有的MSI文件反编译成适当的WiX XML格式,然后研究它如何组合在一起。 非常有用和教育 – 特别是对于高级function。
  • 目前和未来的版本。
    • 版本3.1是稳定和出(2017年5月发布)。 坚如磐石
    • 版本4在这一点上已经有八年的时间了(2017年8月)。
      • 目前还不清楚何时能够稳定发布。
      • 这显然是一个非常重大的更新 ,需要对现有的WiX文件进行大量的重做来成功地使用。
      • 我不能提供任何细节在这一点上的主要分歧。
      • 版本3的稳定性和可靠性无疑得以保留。

高级安装程序

  • 我没有使用这个真正的发展。
  • 非常容易使用,很好的GUI。
  • 就我所知,以专有文本格式存储项目。
  • 看起来不错 ,并且通过一个良好的graphics用户界面隐藏了一些MSI的复杂性 ,它显示直观的checkbox和选项,而不是SDK风格的标志和属性。 这是一件好事,在这一点上完全从WiX中失踪。
  • 看起来这可能是原型和testing,非常强大的graphics用户界面和常用functionautomagic
  • 我错过了InstallShield的发布视图及其发布标志,构build自动化设置以及其他发布pipe理function(现在可以改进)。
  • 总的来说,这是一个非常适合寻求简单方法部署应用程序的开发人员坚实工具 。 类似智者在这方面。
  • 也可用于其“ build筑师版 ”的企业重新包装
  • 太多的实践经验,写更多。 试试看。

其他工具

  • Orca是免费的Windows SDK工具,它允许打开,编辑二进制MSI文件并在一定程度上进行比较。 它还允许其他操作,例如生成转换文件来修改MSI文件和其他一些技术操作。 我总是喜欢安装和使用的基本工具。 在这里有一个更广泛的Orca段落讨论它的使用(看底部)。 您通常必须安装Windows SDK以获取Orca(只需安装最新版本并search该工具)。
  • 一个叫“ Super Orca ”的免费工具已经推荐给我了,就像“ InstEd ”一样。 我只是简单地使用了它们,但是它们看起来不错,而且比Orca更容易获得(不需要下载Windows SDK)。
  • 还有很多其他工具 。 以下是来自http://www.installsite.org的工具列表,其中列出了该工具是否仍在积极维护: http : //www.installsite.org/pages/en/msi/authoring.htm感谢菲尔·威尔逊的链接 – 我不能复活他的答案)。
  • 我想我还可以包括一个链接到维基百科的安装软件列表

工具build议?

这不是我的地方,直接的工具build议。 但我想我可以做一些“观察”,并提供一些进一步的决策链接。

对于任何严重的内部开发团队,我都会build议使用WiX。 在其他工具易于使用的地方,WiX在其灵活性,可扩展性,稳定性以及XML文本源文件的使用方面都有出色的performance,并且有一定的处理能力。 由于其免费许可,每个开发人员都可以查看和编译源代码,更改可以轻松跟踪,恢复或批准。 虽然与开发人员共同pipe理一个进程,所有更新一个WiX源代码仍然有其挑战(与常规开发工作无异 – 没有什么是容易的)。

对于公司重新包装 (这确实是一个超出了stackoverflow.com的开发人员重点)我猜目前的主要选项是Flexera AdminStudio高级安装程序架构师 。 还有其他产品可用,并一如既往installsite.org有详细信息: 工具:重新包装和企业部署

对于寻求快速简便的部署应用程序的小型开发团队 ,我猜InstallshieldAdvanced Installer是最常见的“基于GUI”的工具。 但是,可以使用WiX来提供一个优秀的安装程序。 有一个学习曲线,并有一些严重的限制 – 特别是在目前的GUI方面 – 但基础技术是非常坚实和自由的。 而且重要的是还有许多其他工具 (来自http://www.installsite.org的列表),可能更适合您的任务; – 特别是如果它是一个简单的应用程序,只需要基本的部署function。 我没有提供有关这些工具的更多信息是“不公平的”,这些工具是非常有能力,但较less使用或build立的。

最后请注意高级安装程序InstallShield 明智的 一般允许打包虚拟化软件。 至今为止,我还没有意识到这个WiX的任何function。 请添加评论或只是编辑这个post,如果你有信息在这里。


顶部实用提示

如果我有select,我通常使用其他工具进行原型devise和使用WiX进行实现。 您可以使用WiX的dark.exe (MSI反编译器)来反编译现有的MSI文件。 有时我在Wise或InstallShield中实现一些东西,编译一个MSI并反编译成WiX格式。 然后我解除WiX标记并转储到我的主要WiX文件中。 工作很好,通常非常快。 这与自动组件创build的heat.exe工具相结合,使我能够在运行一些练习后不到10分钟的时间内打包一个巨大的IIS网站。 之后,我有WiX提供的完全可定制性,易于使用其他工具。


在非.NET的东西的WiX有多好?

WiX通过devise支持所有Windows Installerfunction。 Windows安装程序早于.NET。

我个人比起InstallShield更喜欢WiX,因为

  • XML文本格式允许审查提交,合并分支之间的变化
  • build立自动化应包括设置生成,这与WiX很容易
  • 具有组件组定义的wixlib文件允许模块化设置开发 。 不需要担心依赖关系的依赖性等
  • 没有授权或部署头痛的问题,我们只是将WiX工具集包含在SVN项目的/ tools文件夹中

当我们使用InstallShield时,这些都是痛点。 尽pipe如此,WiX确实有着非常陡峭的学习曲线。

几年来我没有使用InstallShield。 在我上一份工作中,我们把它从NSIS中移走了,主要是因为它的二进制格式使得版本控制变得困难,而且由于源文件几次被破坏,没有恢复的希望。 这当然可能与SourceSafe有关!

然而,最重要的是,这是不必要的复杂。 不要误会我的意思 – 我们正在做一些相当复杂的安装程序,有很多条件path,合并模块和复杂的用户界面,但即使如此,它也太复杂了。

NSIS有一个很棒的插件系统,你可以使用LogicLib插件强制编程 , 自动卸载生成的文件 ,还有很多其他的东西。

你应该检查免费软件Inno Setup :很长一段时间,我使用它,它从来没有让我失望!

我inheritance了一些InstallShield(v12)项目。 这些文件都是文本/ XML,因此没有版本控制问题。 我们有一个使用他们的命令行工具的生成机器,运行良好。 我不喜欢的是(a)每个开发人员席位的成本和(b)错误。

Inno Setup非常强大/灵活,通常有多种方式来完成一个目标,这导致了一个陡峭的学习曲线。 我们有几个版本落后于他们的最新版本(由于其升级成本结构)。 因为我们的产品在Widows上运行,所以如果我们需要切换的话,我可能会首先研究一下MSDN订阅附带的Microsoft安装程序解决scheme。