【问题标题】:Reasons not to use custom actions in Visual Studio Setup project在 Visual Studio 安装项目中不使用自定义操作的原因
【发布时间】:2012-05-22 17:18:45
【问题描述】:

今天早些时候,我与某人讨论,我发现您可以在 Visual Studio 安装项目中使用自定义操作来执行您自己的安装程序类,您通常会使用 InstallUtil 运行这些安装程序类(这对于我正在处理的新项目非常有用)。

该人建议我不惜一切代价避免自定义操作,并指出当您需要使用自定义操作时,您需要提出自己的解决方案,并说这是很多人都认可的事情,并且已经很长一段时间。

我四处搜索,找不到任何人对此表示担忧的单个论坛,我只想知道是否有人知道不应使用自定义操作的任何原因?

我想确保在我的新项目中使用最可靠的解决方案,这让我对我目前的方法有些担忧,但是我正在与之讨论的人无法举例说明原因这是个坏主意,所以我只想确认他们所说的是否成立。

【问题讨论】:

  • 如果您想全面了解这里的历史和最佳实践,请在 Skype 上找我。
  • 顺便说一句,为什么不使用 Visual Studio 安装项目完全是另一回事。

标签: visual-studio wix setup-project custom-action


【解决方案1】:

我有很多理由,但这是一个漫长而主观的谈话。这里有几个链接可以帮助您入门。总而言之,要记住的是维护 MSI 的声明性本机(作者表数据驱动,事务性自定义操作),并且真的很难不将脆弱性引入您的安装程序。由于 InstallUtil / Installer 类自定义操作的设计,它们只是一个非启动器。改用 WiX 的 DTF(部署工具基金会)托管的自定义操作项目类型(C#/VB.NET)。

Managed Code CustomActions, no support on the way and here's why

Custom actions are (generally) an admission of failure

注意,对于第一个链接,由于 DTF 的发布,“技术”部分是 OBE。 IMO 的战略部分有些乐观,并在第二个链接中进行了更多讨论。以下是我自己博客的一些背景资料:

MSI vs .NET

The Price of Ideology and a Great New Hope

Deployment Tools Foundation (DTF) Managed Custom Actions

【讨论】:

  • 非常感谢阅读材料!刚刚看完了这一切,但我现在对现在去哪里感到有点不知所措/困惑。我最初使用自定义操作的原因实际上是我可以纯粹在安装项目中做的事情 - 添加一些注册表项。我在您的其他评论中看到您建议设置项目可能值得避免,所以我现在对继续使用我当前的解决方案感到有点怀疑。您是否碰巧有任何适合 WiX / DTF 新手的阅读材料?
  • 我还应该补充一点——我对部署开发非常陌生,我过去的所有开发都是不需要设置的。此安装程序的目标是在用户启动应用程序之前注册一个 DLL 并添加一些注册表项。
  • 我赞扬你很早就意识到 MSI 是一个完全不同的野兽。那里有一些 wix 教程网站,出版了 packetpub 的书,当然还有 wix 用户邮件列表。如果安装真的像你说的那么简单,由于我的经验水平,我可以在大约 15 分钟内给你写出来。
  • 如果您能够编写一个完全符合您需要的安装程序,它永远不会导致修复,您没有任何 CA 并且您不希望您的安装变得更复杂,那么继续坚持下去。意识到安装项目在 VS11 中消失了,因为 MSFT 最终杀死了它。否则,我建议切换到 WiX 和/或 InstallShield Limited Edition。 (VS 客户免费)还有另一种方法:blog.iswix.com/2011/03/…
  • 我昨晚在阅读时碰巧遇到了那个(安装项目不再使用 VS 部署),我认为这可能是一个好兆头学习 WiX!也非常感谢您提供写它的机会,但我会坚持下去,因为它应该是一个很好的学习经历(一个好的,或者一个头发撕裂的!)
猜你喜欢
  • 2011-09-06
  • 2021-11-22
  • 2012-01-26
  • 1970-01-01
  • 2018-02-24
  • 1970-01-01
  • 2023-03-29
  • 1970-01-01
  • 2015-09-05
相关资源
最近更新 更多