【问题标题】:Simple WiX Custom Action in Custom UI Ends Prematurely with Windows 7自定义 UI 中的简单 WiX 自定义操作在 Windows 7 中提前结束
【发布时间】:2018-10-19 09:40:04
【问题描述】:

我的 WiX 安装程序 UI 在使用自定义操作时出错。 有趣的是,安装程序在 Windows 10 中运行良好,但在 Windows 7 上启动时,安装程​​序被中断。

从安装程序日志中,错误代码显示为2896。 谷歌进一步搜索错误代码,指出它可能是 .net 框架版本不匹配。所以我修改了我的CustomAction.config 如下:

<startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0" />
        <supportedRuntime version="v3.0" />
        <supportedRuntime version="v3.5" />
        <supportedRuntime version="v2.0.50727"/>

</startup>

我通过以下命令验证了安装的版本:

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP"

这里还有什么我想念的吗?

编辑: 这是供您参考的自定义操作代码:

namespace ValidateIP
{
    public class CustomActions
    {
        [CustomAction]
        public static ActionResult ValidateIP(Session session)
        {
            session.Log("Begin ValidateIP");
            if (string.IsNullOrEmpty(session["IPVAL"]))
            {
                session["VALIDIP"] = "0";
            }
            else
            {
                session["VALIDIP"] = "1";
            }
            return ActionResult.Success;
        }
    }
}

【问题讨论】:

  • 也许可以尝试使用额外的调试信息进行详细日志记录,并在不缓冲的情况下直接写入(以防止由于崩溃而丢失日志缓冲区):msiexec.exe /i C:\Path\Your.msi /L*vx! C:\Your.log 并查看您是否获得有关运行时错误的更多信息。
  • 可能您的自定义操作是针对特定 .Net 框架版本构建的 .Net 自定义操作,该版本在运行安装程序的目标计算机上可能不可用。
  • @PankajKapare 能否请您查看我的评论以获取 Stein 的答案。
  • @Rahul:好吧,您的自定义操作有多基本和微不足道并不重要。如果自定义操作 dll 是为 .Net 4.7 构建的,并且如果您在目标机器上只有 .Net 3.5,那么它就无法工作。
  • @PankajKapare 正确,但我也刚开始使用 wix,所以对它没有完整的了解。顺便说一句,我已经用我的代码更新了这个问题,请你检查一下。

标签: wix windows-installer custom-action wix3.5 wix3.8


【解决方案1】:

事实证明,虽然我在 CustomAction.config 文件中使用了不同的 .Net 版本,但在 Custom Action 项目中,目标 .Net 版本是 4.5。所以它取代了配置属性。一旦我将它降低到 3.5,它就开始工作了。 谢谢大家的建议。

【讨论】:

  • 我的一个非常有争议的观点:我对此和many other reasons 的托管代码 CA 持怀疑态度(接近底部,可能有点超过顶部)。犹豫不决地,我建议将 VBScript 用于只读 GUI 序列自定义操作,这与该领域许多专家的建议相反。 Windows Installer 托管 ActiveScripting 运行时 - 它将运行(除非出现严重的恶意软件和系统损坏)。 There are many good reasons to avoid (complex) VBScripts.
  • 专家知道,一旦您将 VBScript 用于一些简单的事情,您会经常遇到需求的变化,这使得您的简单只读、仅 GUI 序列的 VBScript 变成了真正的噩梦。我们知道它往往会变成邪恶的东西 - 因为它被更改为进行系统更改(不再是只读的),并在您尝试实例化 COM 服务器并失败并写入被安全软件阻止的不安全位置时触发安装失败。还有一个大问题:脚本代码总体上缺乏可调试性 - 以及缺乏语言功能会让您大吃一惊。
  • 最后结束:将来所有自定义操作都可能会得到管理——一旦我们对最严重的陷阱进行了排序。那么我们可能会看到比原生代码更好的运行时安全性?目前,在我看来,VBScript 在“傻瓜之战”中战胜托管代码有两个核心原因:1)运行时依赖性/可靠性(最近的操作系统版本积极修复损坏的 ActiveScripting 和 COM 组件),2)脚本允许在您的MSI(你知道你的设置中有什么代码库 - 只需提取它 - 没有源代码控制问题和混乱,因为源代码丢失)。
【解决方案2】:

我不是托管代码自定义操作方面的专家,Chris Painter 是这方面的专家,但让我检查几件事:

  • 此自定义操作是否需要管理员权限?
  • 如果是,是否将其配置为在系统上下文中运行的延迟模式自定义操作?
  • 自定义操作按什么顺序运行?图形用户界面?执行?两者都有?
  • 自定义操作实际上在做什么?
  • 自定义操作依赖于哪些 .NET 类和 .NET 功能以及 Widows 功能? (据我们所知,您可能正在实例化 COM 服务器)

详细、调试、日志记录See installsite.org on logging。从该内容中,我会尝试:

msiexec.exe /i C:\Path\Your.msi /L*vx! C:\Your.log

这是完整的、详细的日志记录 (*v),带有额外的调试信息 (x) 和连续日志记录 (!)(而不是批量写入日志)。后者使安装速度慢得多,但确保不会因崩溃而丢失日志缓冲区。


一些链接(用于保管):

【讨论】:

  • 这是一个非常基本的操作,我将在自定义对话框的编辑文本中取一个值,当用户按下下一个时,它会检查该值是否为空。它是 GUI 序列的一部分。而且我真的怀疑它取决于任何.Net 功能。我尝试用详细的方式调试日志,即使这样也没有给我任何额外的信息。
  • @Rahul 如果没有一些额外的工作,您将无法从通过 DoAction 事件启动的操作中获取日志。 msdn.microsoft.com/en-us/library/aa368322(VS.85).aspx 有一些方法可以进行日志记录,但涉及更多。您可能会启动一个消息框并将调试器附加到该消息框以调试您的自定义操作。
  • 是的,我总是参考this article by Robert Dickau 进行自定义操作日志记录。
猜你喜欢
  • 1970-01-01
  • 2015-02-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多