安装程序功能,WIX vs InstallShield Express [英] Installer capabilities, WIX vs InstallShield Express

查看:257
本文介绍了安装程序功能,WIX vs InstallShield Express的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

实际上将产品推广到生产的程序员需要一个安装程序。 (pre-emptiveprogramming relatedjustificaton。)



为了部署一套新的内部公司应用程序和服务,我正在尝试使用WIX和InstallShield Visual Studio 2010附带的快速版。



我已经看过,但还没有找到一个突出显示不在快速版中的功能的功能矩阵。我希望WIX通常能够很好,但更难使用,并且听说过 WIX的情况不能很好地支持。



有没有人找到一个功能矩阵,还是有其他建议,以便长期管理内部部署的最佳方式? p>

解决方案

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




  • 设置定义以XML格式存储


  • 很容易集成到您的自动构建

  • 部分设置可以是自动生成

  • 它允许您定义小的可重用模块并管理它们之间的复杂依赖关系。

  • 没有费用或许可问题(之前我们都必须使用一个Installshield PC)



为什么XML格式是一个优点:这允许您充分利用代码版本控制系统,如颠覆或汞。检查变更,检查历史,甚至合并各分支机构之间的变化是一件轻而易举的事情。将其与不透明的二进制blob的installshield项目进行比较。



我通过管理复杂的依赖关系来表示:在我们的例子中,我们有一个大的可重用组件库,它们之间的依赖关系,以及建立在其上的许多应用程序。在wix之前,这是一个噩梦,当某个地方引入了新的依赖:所有设置都必须更新。



现在用wix,我们有一个 ComponentGroup 为每个库,组织成一对夫妇 wixlibs 。每个组件组都使用 ComponentGroupRef 参考其它组件组。应用程序设置开发人员只需要引用直接依赖关系的组件组,并且wix将通过跟随引用来执行其他操作。因此,引入新的依赖关系仅需要进行单一的本地更改。我们的自动化构建和wix完成其余的重新生成所有设置。


Programmers that actually promote their products to production need an installer. (pre-emptive "programming related" justificaton.)

For deploying a new suite of internal corporate apps and services, I'm trying to decide between using WIX and the InstallShield Express edition that comes with Visual Studio 2010.

I've looked, but haven't found a feature matrix that highlights the features that are not in the express edition. I expect WIX to be generally quite capable, but more difficult to use, and have heard of situations that WIX doesn't support well.

Has anyone found a feature matrix, or have other recommendations on the long-term best way to manage internal deployments?

解决方案

I find that wix is a great choice (in spite of the very very steep learning curve) if you need to manage installers in a complex environment because

  • setup definitions are stored in an XML format
  • it gives you full control to the underlying windows installer technology; the XML schema typically closely follows the windows installer database schema (which is also the main reason why the learning curve is so steep)
  • It is easy to integrate into your automated build
  • Parts of the setup can be generated automatically
  • It allows you to define small reusable modules and manage complex dependencies between them.
  • no cost or licensing issues (before wix we all had to use a single "Installshield PC")

Why the XML format is an advantage: this allows you to fully leverage code versioning systems like subversion or mercurial. Reviewing changes, examining history or even merging changes across branches is a breeze. Compare that to installshield projects which are opaque binary blobs.

What I mean by managing complex dependencies: in our case we have a big pool of reusable component libraries with a complex set of dependencies between them, and many applications that were build on top of that. Before wix, this was a nightmare when a new dependency was introduced somewhere: ALL setups had to be updated.

Now with wix, we have a ComponentGroup for each library, organized into a couple wixlibs. Each component group references other component groups that it depends on with a ComponentGroupRef. Application setup developers only need to reference the component groups of direct dependencies, and wix will do the rest by following the references. As a result, introducing a new dependency only requires making a single local change. Our automated builds and wix do the rest to regenerate all the setups.

这篇关于安装程序功能,WIX vs InstallShield Express的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆