我有一个使用asp.net 3.5开发的非常庞大的Web应用程序,我需要准备一个安装程序包,用于在IIS 6和7上部署应用程序。我已经对Wix和Installsheild 2010做了大量研究(亲)在做出决定之前需要一些建议。我注意到installsheild在许可方面是相当费用的,但对我来说,我有足够的预算,所以这不会是一个问题。安装程序应该能够执行以下过程。
部署已发布的网络资源 (aspx等)。
创建虚拟 目录。
在sql上创建数据库 服务器并运行一些初始化 脚本。
修改XML文件和 web.config文件。
设置 允许写入的权限 虚拟目录中的文件。
我发现这两种技术都能够完成上述方案,但我希望获得个人经验和建议。
答案 0 :(得分:23)
创建了一个Wix安装程序来完成你想要做的事情,我很乐意推荐它。
我认为Wix比InstallShield的好处:
为了平衡这一点,有几点需要注意:
答案 1 :(得分:16)
根据我对Wix和InstallShield的经验,我建议使用InstallShield,除非你需要一个相当基本和简单的安装程序。我之所以这么说,是因为缺乏可用信息,Wix学习曲线变得更加困难
Wix上没有图书,所以您的资源仅限于the Wix tutorial,这篇文章详细而冗长,但仍然没有超出基本要求和您通过Google找到的博客文章。当然,有许多好的博客文章详细介绍了如何完成特定的事情,但除非你没有最后期限,否则你可能无法坐下来研究如何在Wix中做几天的具体事情。就个人而言,我发现自己这样做太过于让Wix成为一个可行的解决方案(再次,除非你只需要一个简单的安装程序)
最终,在我的情况下,我们使用InstallShield开发了现有的安装程序,我们可以更快地使用它。 InstallShield也有自己的脚本语言,它也有很好的文档。
另一个重要的优点是,InstallShield可以减轻多个实例的痛苦(尝试使用Wix搜索如何执行此操作,并且您将了解我所说的内容)以及升级/修补。我能够使用InstallShield在分数中完成这两个(特别是多个实例),而不是在Wix中完成它。
我的建议是根据您的时间限制/截止日期/承诺,安装程序的复杂性以及产品的成熟度进行选择。 Wix需要大量研究,因为InstallShield提供了一种相当快速的方法。如果你有一个成熟的产品而不是一个相当年轻的产品,这可能会更加痛苦。
希望这有帮助。
答案 2 :(得分:12)
要解决上面撒母耳的观点......
我在CodePlex上创建了一个名为IsWiX的项目,解决了民主化问题。您可以将它与WiX一起使用来创建合并模块,然后将合并模块与InstallShield一起使用以获得两全其美的效果。这允许安装人员使用InstallShield和我的几十个开发人员使用IsWiX / WiX。 XML仍然可以使用其他元数据进行标记,因此我们不限制模块可以描述的内容。
InstallShield有一个独立的构建引擎,它与MSBuild / TFS集成并提供自动化接口。这里的WiX没有优势。
InstallShield也是一个文本文件。这是一种更丑陋的DTD格式,但IsWiX通过从安装程序中很少变化的部分抽象出频繁变化的部分来解决这个问题。
我强烈建议在InstallShield中使用DTF。毕竟,类型1导出的函数与任何基于MSI的工具相同。
InstallShield有一个直接编辑器,可以显示基础表。这实际上更接近金属,然后使用基于XSD的DSL输出金属的WiX。 总而言之,WiX AND InstallShield确实很好用,我一起使用它们来创建极其复杂的安装程序。
PS- IsWiX在散列和排序方面投入了大量精力来解决分支合并问题。 (我们在几十个分支上使用Base Clearcase,所以这对我们来说非常重要。)
答案 3 :(得分:8)
+1给Samuel的回答。至于陡峭的学习曲线......如果您不了解底层技术(Windows Installer)的工作方式,您将无法获得安装支持,无论是您选择的InstallShield还是WiX。但WiX鼓励您学习Windows Installer以正确使用WiX抽象。
我亲自使用InstallShield启动了我的安装项目(一个巨大的Web应用程序),但我最近搬到了WiX,我很高兴。我选择的关键点:
希望您发现此信息有用。