windows - Windows Installer在Win 10上失败，但在使用WIX的Win 7上失败

Question

最近，我被指派更新我们的项目安装程序以在Windows 10上运行，而我对如何使其工作不知所措。我没有安装程序的经验，并且不仅要熟悉整个过程，而且要熟悉我们项目的处理方式。

截至目前，安装程序可以在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虚拟机上以相同的权限运行安装程序。

我怀疑这是否足够的信息才能得到任何具体的回应，所以我正在寻找 build 性的建议，如如何看待和如何解决这一问题。我可以发布更多详细信息，但是信息量如此之大，而且我不知道该如何选择真正相关的信息。

Answer 1

将其添加为答案-注释太长，我认为这也是正确的答案。如果您阅读此答案，请也从上方查看我的评论，以获得Rob Mensching(WiX的创建者)非常好的MSI日志文件调试技巧-以及如何通过启用崩溃的“刷新日志”功能来确保所有条目都进入日志文件自定义操作。

答案

对缺少像Powershell这样的运行时的依赖肯定会触发回滚。 MSI为某些脚本自定义操作(active scripting)托管其自己的运行时。例如VBScript和JavaScript。为了可靠地进行部署，建议所有使用的自定义操作要么是自包含的最低依赖性C++ dll或可执行文件(win32)，要么是(不太理想的)VBScript或JavaScript(如果使用Installshield，甚至是Installscript-请参见下面的详细信息)。

我的有争议的观点:用于可靠性和健壮性的最差的自定义操作是需要特定版本.NET框架的.NET二进制文件。这也适用于PowerShell-它不仅是托管代码，而且是脚本。我很想说这些技术不应该用于部署，但是如果您需要使用PowerShell，则必须至少在安装开始时添加一个“验证已安装PowerShell”自定义操作，并以如果PowerShell不可用，则会显示(和/或记录)正确的错误消息。

真正的答案到此为止:-)。如果您要制作一个用于一般发行的软件包(而不仅仅是您自己公司内部部署的软件包)，则下面是一些“冗长的沉思”。如果我是您，即使您仅在内部进行部署，我也会读它， PowerShell自定义操作可能是 Eloquent 的酝酿部署问题。

托管代码和脚本都有问题。 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 Framework时，不能保证您会拥有适当的运行时环境。

详细的沉思

我不确定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所希望的，但有时您需要编译的二进制文件才能隐藏实现细节(例如，当您验证许可证 key 时)。这样就不能使用任何类型的脚本-显然。通过透明并且还嵌入到MSI中(因此始终可以获取完整的运行源代码)，它可以帮助不同的应用程序包装商在需要时承担其他人的工作。在部署团队中，总会有人来调试脚本-但很少有人可能知道正确的C++。在内部应用程序开发人员在没有太多部署知识的情况下制作自己的MSI文件的公司中，脚本编写可能会完全误入歧途，并导致非常困难的部署问题。通常，需要对应用程序本身进行小的更改以允许更可靠的部署。例如，应用程序应该进行自己的启动配置-不应在安装脚本中完成所有操作，但是许多开发人员都可以这样做。

使用脚本自定义操作存在争议。 如果您询问2位开发专家，您将获得4条意见。在我看来，“白框”自定义操作(脚本)如果做一些不常见的特定操作，则可以用于公司，这样人们就可以看到发生了什么。对于一直需要的内容，公司应在MSI文件中创建由自定义表驱动的经过编译的C++ dll，并提供全面的质量检查和回滚支持-所有脚本自定义操作通常都缺少这种东西(实行)。 “数据驱动”(定制表)C++定制操作具有最大的优势，即具有最小的依赖关系，并且也是透明的(将发生的事情是透明的，但是实际实现被编译和隐藏了，这也可以提高安全性)。 WiX工具包提供了这样的自定义操作dll，并以C++编写了回滚支持。它应该解决企业部署所需的大多数自定义任务。 尽管这一切都超出了您的问题-只是题外话:-)。

如果我猜到了，我会说Windows Installer可能已更新为能够托管Powershell自己的运行时-但这只是猜测。我不确定技术细节-似乎需要整个.NET运行时？如果您问我，相对于PowerShell脚本，我仍然会更喜欢JavaScript，但我知道您可能致力于将PowerShell作为公司标准？同样，总是比VB脚本更喜欢JavaScript，因为它看起来像异常处理(VB Script完全缺少)。 更新:实际测试表明，与Javascript相比，VBScript实际上更适合与MSI一起使用。例如:在使用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 Framework的目标版本不再运行而突然无法卸载的软件包？ 解决这个问题可能是一项令人难以置信的工作，尤其是对于拥有大量包装 Assets (数千个包装，数千台机器)的公司而言。

推荐的自定义操作实现

我撰写了有关自定义操作实现的“建议”摘要。它长篇幅不多说-我删除了它。相反，这是我的自定义操作实现首选项的列表(以降低健壮性和可靠性的顺序):

更新，2018年5月:不再推荐基于VBScript的Javascript。

C++ dll

安装脚本(仅InstallShield)

VB脚本

JavaScript

C#DTF

PowerShell

概括:

对我而言在编写本文时，PowerShell 绝对是最糟糕的选择。 托管代码(运行时不可靠)，和都是脚本自定义操作(调试不良)。

为了简化起见，我想像Chris一样编写 C#/DTF自定义操作，但是我不相信时机成熟-无法保证运行时环境。在现实世界中，您不会抛出支持C#dll的有效C++ dll。这是一个巨大的可靠性降级。

C++ dll 和安装脚本是的唯一选择，它们是针对不同计算机(不是受管理环境中的标准台式机-公司，而是世界上处于异质状态的世界各地的计算机，以不同的语言)进行专业，供应商设置的唯一选择。以及各种硬件和软件配置)。

一个 C++自定义操作dll 与它的导出，构 build 置和输出相比，比其他自定义操作更难以设置和配置，但这并不是不可思议的。作为返回，您得到了很多:完整的调试功能，高级语言功能和错误处理。最重要的是:最小依赖性(确保启用静态链接以消除所有可能的依赖性)。对于调试，您可以简单地将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触发意外错误而导致主要的部署问题。