截至目前,安装程序在我们的Windows 7 VM上运行完美,但在Windows 10 VM上运行时,它会在接近结束时失败并开始回滚.我已经把它吐出一些日志文件,我正在挖掘它们但是相当丢失.
我跟踪了这一点：
MSI (s) (B0:F4) [17:39:02:883]: Note: 1: 1708 MSI (s) (B0:F4) [17:39:02:883]: Note: 1: 2205 2: 3: Error MSI (s) (B0:F4) [17:39:02:883]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1708 MSI (s) (B0:F4) [17:39:02:883]: Note: 1: 2205 2: 3: Error MSI (s) (B0:F4) [17:39:02:883]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI (s) (B0:F4) [17:39:02:883]: Product: GPEP -- Installation failed.
接近最终似乎发生在安装程序似乎失败时或附近.
下一行最后有这个：
Installation success or error status: 1603.
我调查了错误,发现了这个：Error 1603
我正在调查该页面上的解决方案,但所有这些都应该是有序的.我们以相同的方式运行安装程序,在Win 10和Win 7 VM上具有相同的权限.
我怀疑这将是足够的信息来获得任何具体的反应,所以我正在寻找建设性的建议,如何看待以及如何解决这个问题.我有更多可以发布的详细信息,但信息量如此之多,我不知道如何找出真正相关的内容.
答案
对像Powershell这样的缺失运行时的依赖肯定会触发回滚. MSI为某些脚本自定义操作(active scripting)托管自己的运行时.例如VBScript和JavaScript.为了可靠部署,建议使用的所有自定义操作都是自包含的最小依赖性C dll或可执行文件(win32)或(不太理想的)VBScript或JavaScript(如果使用Installshield,则甚至是Installscript – 请参阅下面的详细信息).
我的争议观点：用于可靠性和健壮性的最糟糕的自定义操作是.NET二进制文件,需要特定版本的.NET框架.这也适用于PowerShell – 它不仅是托管代码,还是脚本.我很想说这些技术不应该用于部署,但是如果你需要使用PowerShell,你必须至少在安装开始时添加“验证PowerShell安装”自定义操作,并优雅地退出如果PowerShell不可用,则显示(和/或记录)正确的错误消息.
这是真正答案的结束:-).以下是一些“冗长的思考”,以防您正在制作一般分发包(而不仅仅是您公司内部部署的包).如果我是你,我会读它,即使你只在内部部署,PowerShell自定义操作可能是一个口径的酿造部署问题.
托管代码和脚本都存在问题. PowerShell实际上是有效的. Here is Rob Mensching’s blog on why script custom actions are bad.基本上：脚本是脆弱的,它们缺乏语言功能,很难调试,反病毒产品通常会阻止它们.阅读博客.并且here is Aaron Stebner’s blog on why managed code is bad.当您依赖.NET框架的存在时,基本上不能保证适当的运行时环境.
详细的冥想
我不确定Win7和Win10上标准安装的是什么.如果您要部署为公司的“内部包”,我认为只需添加对PowerShell存在的可靠检查,然后如果找不到PowerShell则中止有意义的错误消息.意见警告：但是整体.NET二进制文件和PowerShell脚本是可靠性最差的自定义操作.我绝不会将它们用于针对不同计算机的设置.
如果您要将MSI一般分发到任何地方的任何计算机,我会花时间将PowerShell脚本转换为其他内容.最好是C dll – 我觉得最可靠.没有依赖性或依赖的层.如果你一直使用Installshield,它甚至可以接受InstallScript(它可以在没有预先安装的运行时运行 – 这显着提高了它的可靠性和实用性 – 虽然语法相当陈旧,但它是一种迟钝的语言.公平地说,不是被低估 – 它完成了工作,并且比C更简单.
JavaScript和VBScript自定义操作甚至可以用于一般分发到任何计算机的MSI,但仍然不推荐使用.我倾向于仅将它们用于“内部公司部署”包.这些可以是标准化的,关键的是脚本对其他系统管理员和打包者是透明的.他们可以查看和检查安装过程中正在执行的操作.这通常是可取的和one of the key benefits of MSI for corporate deployment,但有时您需要编译二进制来隐藏实现细节(例如,当您验证许可证密钥时).然后,任何类型的脚本都不能使用 – 显然.通过透明并嵌入在MSI中(因此,完整的,运行的源始终可用),它可以帮助不同的应用程序打包者在需要时能够获取其他人的工作.在部署团队中总有人可以调试脚本 – 但很少有人知道正确的C.在内部应用程序的开发人员在没有太多部署知识的情况下制作自己的MSI文件的公司中,脚本编写可能完全误入歧途并导致非常困难的部署问题.通常需要的是对应用程序本身的小改动,以允许更可靠的部署.例如,应用程序应该执行自己的启动配置 – 这些都不应该在安装脚本中完成,但许多开发人员会这样做.
使用脚本自定义操作是有争议的.如果您询问2位开发专家,您将获得4个意见.在我看来,“白盒子”自定义动作(脚本)对于企业用途是有益的,如果他们做一些不常见的特定事情,那么人们可以看到正在发生的事情.对于一直需要的东西,公司应该使用MSI文件中的自定义表驱动编译的C dll,并提供完整的QA和回滚支持 – 这对于所有脚本自定义操作通常总是缺失(这对于实行). “数据驱动”(自定义表)C自定义操作具有最小的依赖性作为其最大优势,并且它也是透明的(将发生什么是透明的,但实际的实现是编译和隐藏的 – 这也可以提高安全性). WiX工具包提供了这样一个带有用C编写的回滚支持的自定义动作DLL.它应该解决企业部署所需的大多数自定义任务.所有这一切都超出了你的问题 – 只是一个题外话:-).
如果我猜测我会说Windows Installer可能会更新为能够为Powershell托管自己的运行时 – 但这只是猜测.我不确定技术细节 – 似乎需要整个.NET运行时？如果你问我,我仍然更喜欢JavaScript到PowerShell脚本,但我意识到你可能已经承诺将PowerShell作为公司标准？此外,总是喜欢JavaScript而不是VB脚本,因为它看起来像异常处理(VB脚本完全缺乏).更新：实际测试表明VBScript实际上更适合与MSI一起使用而不是Javascript.例如：我在使用Javascript访问MSI API时遇到了一些模糊的问题. MSI本身可能使用VBScript进行了更多测试,而不是使用Javascript进行测试.老实说：两种“语言”都有严重的局限性,而且两者都难以调试.
Rob Mensching,Chris Painter,Phil Wilson,Bob Arnson以及其他人(我不确定Stefan Kruger’s在脚本上的位置,或者Robert Dickau的观点) – 会因此而杀了我,但这里是JavaScript自定义动作的模板(未经测试)由我,但看起来不错)：How to debug an MSI Custom Action that is implemented in Javascript?.如果我可以脱口而出：目前任何东西都比PowerShell更好 – 甚至是JavaScript.
请放心,我浪费了大量时间调试极其糟糕的VB Script自定义操作.可能是用于部署的最无能和最无用的语言. On Error Resume Next进行错误处理？它不会变得更糟.我通常只使用脚本进行只读操作和设置属性操作.
也许我们会看到VB脚本被弃用,PowerShell在适当的时候被添加为可行的MSI脚本选项？在使用的所有操作系统至少安装了.NET框架的基准版本之前,我不会认为这是安全的 – 即便如此,我相信策略可以锁定特定版本的.NET.您是否想要一个突然无法卸载的软件包,因为.NET框架的目标版本不再可用？解决这样一个问题可能是一项令人难以置信的工作量 – 特别是对于拥有大型软件包(数千个软件包,数千台机器)的公司而言.
推荐的自定义操作实现
我写了自定义操作实现的“建议”摘要.它变得很长,没有多说 – 我删除了它.相反,这是我的自定义操作实现首选项列表(按降低稳健性和可靠性的顺序)：
更新2018年5月：不再推荐Javascript超过VBScript.
> C dll
> Installscript(仅限InstallShield)
> VB脚本
> JavaScript
> C#DTF
> PowerShell
概要：
>对我来说,PowerShell在编写绝对是最糟糕的选择时.它既是托管代码(不可靠的运行时),也是脚本自定义操作(调试不佳).
>我想编写像Chris这样简单的C#/ DTF自定义操作,但我不相信时机成熟 – 无法保证运行时环境.在现实世界中,你不会抛弃一个有效的C dll,转而使用C#dll.这是一个巨大的可靠性降级.
> C dll和Installscript是制作针对不同计算机的专业供应商设置的唯一选择(不是托管环境中的标准化桌面 – 公司,而是世界上任何地方的所有异构状态,不同语言和不同硬件和软件配置的计算机) ).
>使用其导出,构建设置和输出,C自定义操作dll比其他自定义操作设置和配置要困难得多,但这并非神奇的不可能性.作为回报,您可以获得很多：完整的调试功能,高级语言功能和错误处理.最重要的是：最小的依赖关系(确保启用静态链接以消除所有可能的依赖关系).对于调试,您只需将Visual Studio调试器附加到自定义操作显示的消息框中,然后您就可以单步执行代码.这适用于用户和系统上下文自定义操作.完全控制.这实际上使调试C自定义操作比脚本自定义操作更容易,当然更可靠.
>我通常会避免使用JavaScript.它只是一种完整的语言.我仍然认为它比托管代码更可靠 – 在运行时依赖性和可靠性方面(运行时依赖性缺陷更少).
> VB脚本可用于托管环境中的“内部企业使用”.我绝不会将它用于供应商设置以进行一般分发.但是,要在公司网络上分发包,可以使用它.两者都是开发人员打包他们自己的应用程序,以及应用程序打包器调整第三方设置进行企业部署. VBScript操作的主要优点和缺点：
>如上所述,脚本应该仅在极少数情况下使用,并且win32 C dll或WiX的自定义操作dll应该用于人们倾向于重复使用的所有常见脚本任务.只有在需要完成工作时才能使用脚本.
>与所有脚本自定义操作一样,VBScript自定义操作通常难以调试,容易受到反病毒干扰,并且缺乏实现高级编码结构所需的语言功能.您只是没有C语言提供的语言功能和灵活性(现在即使是C自定义操作也可以被安全软件阻止 – 但它并不常见,但是随着安全性的加强可能会改变吗？)
>脚本对每个人都是透明的(目的和实现),并且可以由几个团队成员轻松调试和维护,并在他们之间进行工作.所有人都可以看到正在发生的事情,每个人都可以快速地接受别人的工作.
>嵌入在MSI中的源是正确的源,您不需要在存储库中单独维护源文件来编译它,就像您需要托管代码(C#)一样.对于应用程序打包源控件很少设置是我的经验(应该是).
>企业软件包针对标准操作环境(SOE).使用相同的防病毒解决方案,所有工作站都相似或相同.这显然意味着目标计算机处于比正常情况更加均匀的状态.任何防病毒问题都将被检测到并可以进行管理.就个人而言,我没有看到任何重大的反病毒干扰问题与这种软件包部署的简单脚本.
>在打包团队中,脚本调试往往有很多专业知识,但很少有C知识(很多人知道一些C#和PowerShell).开发人员可能更喜欢C#,但可以轻松处理脚本.
我确信的一件事是,托管代码自定义操作的可用性将导致人们在他们的设置中执行太多的事情,这些事情永远不应该在设置中完成(丰富的API,相对简单的编码).这都是因为编码更容易,更快,而且有问题的开发人员可能缺乏对如何正确部署的理解.这不可避免地导致过度使用各种自定义操作,并且反过来主要部署问题如the complexity of custom actions触发意外错误.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。