Windows 安装程序在 Win 10 上失败，但在使用 WIX 的 Win 7 上失败 [英] Windows Installer fails on Win 10 but not Win 7 using WIX

问题描述

我最近被分配更新我们的项目安装程序以在 Windows 10 上运行，但我不知道如何让它工作.我没有安装安装程序的经验，我正在熟悉这个过程，不仅要熟悉整个过程，还要熟悉我们的项目如何处理它.

I've recently been assigned to update our projects installer to run on Windows 10 and I'm at a bit of a loss on how to get it to work. I have no experience doing installers and am in the process of familiarizing myself not only with the process in general but also how our project handles it.

截至目前，安装程序在我们的 Windows 7 虚拟机上运行良好，但在我们的 Windows 10 虚拟机上运行时，它在接近尾声时失败并开始回滚.我已经让它吐出一些日志文件，我正在挖掘它们，但我相当茫然.

As of now, the installer works perfectly running on our Windows 7 VM, but when running it on our Windows 10 VM it fails near the end and begins to rollback. I've gotten it to spit out some log files and I'm digging through them but am fairly loss.

我已经找到了这一点:

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.

在安装程序似乎失败时或附近发生的接近尾声.

Near the end which seems to occur at or around when the installer seems to fail.

下一行结尾是这样的:

Installation success or error status: 1603.

我查看了错误并发现了这一点:错误 1603

I've looked into the error and found this: Error 1603

我正在研究该页面上的解决方案，但所有这些应该都井井有条.我们以相同的方式运行安装程序，在 Win 10 和 Win 7 VM 上具有相同的权限.

I'm looking into the solutions on that page but all of that should be in order. We're running the installer in the same way with the same permissions on the Win 10 and Win 7 VM's.

我怀疑这些信息是否足以得到任何具体的回应，所以我最重要的是寻找建设性的建议，如何寻找以及如何解决这个问题.我可以发布更多详细信息，但信息量如此之大，我不知道如何挑选出真正相关的内容.

I doubt this will be enough information to get any concrete responses, so more than anything I'm looking for constructive advice how where to look and how to figure this out. I have more details I could post, but it's such a large volume of information and I don't know how to pick out what is genuinely relevant.

推荐答案

添加这个作为答案 - 作为评论太长了，我认为这也是正确的答案.如果您阅读了此答案，还请参阅我上面的评论以获取来自 Rob Mensching(WiX 的创建者) - 以及如何确保所有条目都进入通过为崩溃的自定义操作启用刷新到日志"来记录文件.

Adding this as an answer - it is too long as a comment, and I think it is the correct answer as well. If you read this answer, please also see my comment above for a very good MSI log file debugging tip from Rob Mensching (creator of WiX) - and how to ensure all entries make it into the log file by enabling "flush to log" for crashing custom actions.

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

Dependency on a missing runtime like Powershell would certainly trigger the rollback. MSI hosts its own runtime for certain script custom actions (active scripting). For example VBScript and JavaScript. For reliable deployment, it is recommended that all custom actions used be either self-contained minimum-dependency C++ dlls or executables (win32) or (less desirable) VBScript or JavaScript (or even Installscript if you use Installshield - see details below).

我的争议意见:用于可靠性和稳健性的最糟糕的自定义操作是需要特定版本的 .NET 框架的 .NET 二进制文件.这也适用于 PowerShell - 它不仅是托管代码，还是脚本.我很想说这些技术不应该用于部署，但如果您需要使用 PowerShell，您必须至少在设置开始时添加验证 PowerShell 已安装"自定义操作，并优雅退出如果 PowerShell 不可用，则会显示(和/或记录)正确的错误消息.

Disputed opinion of mine: The worst custom actions to use for reliability and robustness are .NET binaries requiring a specific version of the .NET framework. This also applies to PowerShell - which is not only managed code, but also a script. I am very tempted to say that these technologies shouldn't be used for deployment, but if you need to use PowerShell you must at a minimum add a "verify PowerShell installed" custom action at the start of your setup, and exit gracefully with a proper error message displayed (and/or logged) if PowerShell is not available.

这是真正答案的结尾:-).下面是一些冗长的思考"，以防您正在制作一个用于一般分发的包(而不仅仅是一个用于您自己公司内部部署的包).如果我是你，即使你只在内部部署，我也会阅读它，PowerShell 自定义操作可能是 calibre 的酝酿部署问题.

That is the end of the real answer :-). Below are some "verbose musing" in case you are making a package for general distribution (and not just a package for your own company's internal deployment). If I were you I would read it even if you only deploy internally, PowerShell custom actions could be a brewing deployment problem of caliber.

托管代码和脚本都有问题.PowerShell 同时有效.这是 Rob Mensching 的博客关于为什么脚本自定义操作不好.本质上:脚本很脆弱，它们缺乏语言特性，它们很难调试，而且防病毒产品经常阻止它们.阅读博客.和 这里是 Aaron Stebner 关于为什么托管代码不好的博客.当您依赖 .NET 框架的存在时，基本上无法保证您有一个适当的运行时环境.

Both managed code and scripts are problematic. PowerShell is effectively both at the same time. Here is Rob Mensching's blog on why script custom actions are bad. Essentially: scripts are fragile, they lack language features, they are hard to debug and anti-virus products often block them. Read the blog. And here is Aaron Stebner's blog on why managed code is bad. Essentially you are not guaranteed a proper runtime environment when you depend on the presence of the .NET framework.

我不确定 Win7 和 Win10 上的标准安装是什么.如果您将作为内部包"部署到您的公司，我认为只需添加对 PowerShell 是否存在的可靠检查，然后在未找到 PowerShell 时使用有意义的错误消息中止就可以了.意见警告:但总体而言 .NET 二进制文件和 PowerShell 脚本是可靠性最差的自定义操作.我永远不会将它们用于针对不同计算机的设置.

I am not sure what is installed as standard on Win7 and Win10. If your are deploying as an "internal package" to your company, I think it should be OK to just add a reliable check for the presence of PowerShell, and then to abort with a meaningful error message if PowerShell is not found. Opinion Warning: But overall .NET binaries and PowerShell scripts are the worst custom actions for reliability. I would never use them for setups targeting diverse computers.

如果您正在制作一个 MSI 以便在任何地方的任何计算机上进行一般分发，我会花时间将 PowerShell 脚本转换为其他内容.最好是一个 C++ dll——我觉得它最可靠.没有可言的依赖关系或可依赖的层级.如果您一直在使用 InstallShield，即使 InstallScript 也是可以接受的(此时它可以在没有预安装运行时的情况下运行 - 这大大提高了它的可靠性和实用性 - 它是一种迟钝的语言，尽管语法相当陈旧.公平地说，不要被低估了 - 它完成了工作，并且比 C++ 更简单).

If you are making an MSI for general distribution to any computer anywhere, I would take the time to convert the PowerShell script to something else. Preferably a C++ dll - which I find most reliable. There are no dependencies to speak of or layers to depend on. Even InstallScript is acceptable if you would have been using Installshield (it can run without a pre-installed runtime at this point - which has significantly improved its reliability and usefulness - it is an obtuse language though with rather archaic syntax. In fairness, not to be underestimated - it does the job, and is simpler than C++).

JavaScript 和 VBScript 自定义操作可能 可用于一般分发到任何计算机的 MSI，但仍然不推荐.我倾向于仅将它们用于内部公司部署"包.这些可以是标准化，而且至关重要的是，脚本对于其他系统管理员和打包者来说是透明的.作为安装的一部分，他们可以查看和检查正在执行的操作.这通常是可取的，并且 MSI 对企业的主要优势之一部署，但有时您需要一个已编译的二进制文件来隐藏实现细节(例如，当您验证许可证密钥时).那么任何类型的脚本都不能使用 - 显然.通过透明并且嵌入在 MSI 中(因此完整的、运行的源代码始终可用)，它帮助不同的应用程序打包者能够在需要时获取其他人的工作.在部署团队中，总是有人可以调试脚本——但可能很少有人知道正确的 C++.在内部应用程序开发人员在没有太多部署知识的情况下制作自己的 MSI 文件的公司中，脚本编写可能会完全误入歧途并导致非常困难的部署问题.通常需要对应用程序本身进行小的更改，以实现更可靠的部署.例如，应用程序应该进行自己的启动配置 - 这些都不应该在设置脚本中完成，但许多开发人员都会这样做.

JavaScript and VBScript custom actions are possible to use even for MSIs that are for general distribution to any computer, but still not recommended. I tend to use them only for "internal company deployment" packages. These can be standardized and crucially scripts are transparent to other system administrators and packagers. They can see and inspect what is being done as part of the installation. This is generally desirable and one of the key benefits of MSI for corporate deployment, but sometimes you need a compiled binary to hide implementation details (for example when you validate a license key). Then scripts of any kind can't be used - obviously. By being transparent and also embedded in the MSI (so the full, running source is always available), it helps different application packagers to be able to pick up someone else's work when need be. And in a deployment team there is always someone available to debug scripts - but few may know proper C++. In corporations where developers of internal applications make their own MSI files without much deployment knowledge, scripting can go completely astray and cause very difficult deployment problems. Very often what is needed is small changes to the application itself to allow more reliable deployment. An application should do its own startup configuration for example - none of this should be done in setup scripts, but many developers do this.

使用脚本自定义操作是有争议的.如果您询问 2 位开发专家，您将获得 4 种意见.在我看来，如果白盒"自定义操作(脚本)做了一些不常见的特定操作，那么他们就可以很好地使用，这样人们就可以看到正在发生的事情.对于一直需要的东西，公司应该制作一个由 MSI 文件中的自定义表驱动的编译 C++ dll，并具有完整的 QA 和回滚支持——所有脚本自定义操作通常总是缺少的东西(这并非易事实施).数据驱动"(自定义表)C++ 自定义操作以最小的依赖性作为其最大的优势，而且它也是透明的(将发生的事情是透明的，但实际的实现是编译和隐藏的——这也可以提高安全性).WiX 工具包提供了这样一个自定义操作 dll，它带有用 C++ 编写的回滚支持.它应该可以解决企业部署所需的大多数自定义任务.所有这些都超出了您的问题范围 - 只是题外话:-).

Using script custom actions is controversial. If you ask 2 development experts you will get 4 opinions. In my view "white box" custom actions (scripts) are good for corporate use if they do something specific that isn't common so people can see what is going on. For stuff that is needed all the time, a corporation should make a compiled C++ dll driven by custom tables in the MSI file with full QA and rollback support - something that is generally always missing for all script custom actions (it isn't trivial to implement). A "data driven" (custom tables) C++ custom action has minimal dependencies as its biggest strength, and it is also transparent (what will happen is transparent, but the actual implementation is compiled and hidden - which can also improve security). The WiX toolkit provides such a custom action dll with rollback support written in C++. It should solve most custom tasks required for corporate deployment. All of this is way beyond your question though - just a digression :-).

如果我猜的话，我会说 Windows Installer 可能会更新为能够为 Powershell 托管自己的运行时 - 但这只是猜测.我不确定技术细节 - 似乎需要整个 .NET 运行时?如果您问我，我仍然更喜欢 JavaScript 而不是 PowerShell 脚本，但我知道您可能致力于将 PowerShell 作为公司标准?此外，总是更喜欢 JavaScript 而不是 VB 脚本，因为它有一些看起来像异常处理的东西(VB 脚本完全没有).更新:实际测试表明 VBScript 实际上比 Javascript 更适合与 MSI 一起使用.例如:我在使用 Javascript 访问 MSI API 时看到了一些模糊的问题.MSI 本身在创建时可能更多地使用 VBScript 进行测试，而不是使用 Javascript.老实说:这两种语言"都有严格的限制，而且都很难调试.

If I were to guess I would say that Windows Installer might be updated to be able to host its own runtime for Powershell - but this is just speculation. I am not sure of the technical details - it would seem the whole .NET runtime would be needed? If you ask me, I would still prefer a JavaScript to a PowerShell script, but I realize you are probably committed to PowerShell as a company standard? Also, always prefer JavaScript over VB Script since it has something that looks like exception handling (which VB Script lacks entirely). UPDATE: real-world testing indicates that VBScript is actually better to use with MSI than Javascript. For example: I have seen obscure problems when accessing the MSI API with Javascript. MSI itself was probably tested more with VBScript than with Javascript when it was created. Let's be honest: both "languages" have severe limitations and both are hard to debug.

Rob Mensching、Chris Painter、Phil Wilson、Bob Arnson 可能还有其他人(我不是确定 Stefan Kruger 在脚本中的位置，或 Robert Dickau 的strong> 视图) - 会为此而杀了我，但这是一个 JavaScript 自定义操作的模板(未经我测试，但看起来不错):如何调试在 Javascript 中实现的 MSI 自定义操作? .如果我可以脱口而出:目前任何东西都比 PowerShell 更好 - 甚至是 JavaScript.

Rob Mensching, Chris Painter, Phil Wilson, Bob Arnson and probably others too (I am not sure of Stefan Kruger's position on scripts, or Robert Dickau's view) - will kill me for this, but here is a template for a JavaScript custom action (untested by me, but looks OK): How to debug an MSI Custom Action that is implemented in Javascript? . If I can just blurt it out: anything is better than PowerShell at the present time - even JavaScript.

请放心，我已经浪费了很多时间来调试极其糟糕的 VB 脚本自定义操作.可能是有史以来用于部署的最无能和最受剥夺的语言.On Error Resume Next 进行错误处理?它不会变得更糟.我一般只使用脚本进行只读操作和设置属性操作.

Rest assured, I have wasted a lot of time debugging extremely poor VB Script custom actions. Probably the most incompetent and deprived language ever used for deployment. On Error Resume Next for error handling? It can't get much worse. I generally only use scripts for read-only operations and set property actions.

也许我们会在适当的时候看到不推荐使用 VB 脚本并添加 PowerShell 作为可行的 MSI 脚本选项?在所有正在使用的操作系统都至少安装了 .NET 框架的基线版本之前，我不会认为这是安全的——即便如此，我相信策略可以锁定特定版本的 .NET 以使其无法使用.您是否想要一个由于 .NET 框架的目标版本不再可操作而突然无法卸载的软件包? 解决此类问题可能需要大量工作 - 特别是对于拥有大型包裹资产(数千个包裹，数千台机器).

Maybe we will see VB Script deprecated and PowerShell added as a viable MSI scripting option in due time? I wouldn't judge this as safe until all operating systems in use would have at least a baseline version of the .NET framework installed - and even then I believe policies could lock specific versions of .NET from being used. Do you want a package that suddenly can't uninstall because the target version of the .NET framework is no longer operational? Fixing such an issue could be an incredible amount of work - especially for a corporation with a large package estate (thousands of packages, thousands of machines).

我为自定义操作实施编写了一份建议"摘要.它变成了长页，没有多说 - 我删除了它.相反，这里列出了我的自定义操作实施偏好(按稳健性和可靠性降低的顺序):

I wrote up a summary of "recommendations" for custom action implementation. It became pages long without saying much - I deleted it. Instead, here is a list of my custom action implementation preference (in order of decreasing robustness and reliability): 

更新 2018 年 5 月:不再推荐 Javascript 而不是 VBScript.

UPDATE May,2018: no longer recommending Javascript over VBScript.

1. C++ dll
2. Installscript(仅限 InstallShield)
3. VB 脚本
4. JavaScript
5. C# DTF
6. PowerShell

1. C++ dll
2. Installscript (InstallShield only)
3. VB Script
4. JavaScript
5. C# DTF
6. 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 自定义操作与所有脚本自定义操作一样，通常难以调试、容易受到防病毒干扰和缺乏语言功能strong> 需要实现高级编码结构.您只是没有 C++ 可用的语言功能和灵活性(现在，即使是 C++ 自定义操作也可以被安全软件阻止 - 但它并不常见，但随着安全性的加强，这种情况会改变吗?)
  • 脚本对所有人(目的和实现)都是透明的，并且可以由多个团队成员轻松调试和维护，并在他们之间移交工作.所有人都可以看到正在发生的事情，并且每个人都可以快速接手别人的工作.
  • 嵌入在 MSI 中的源代码是正确的源代码，您不需要像托管代码 (C#) 那样在存储库中单独维护源文件来编译它.对于应用程序打包源代码控制很少设置是我的经验(应该是).
  • 企业包以标准操作环境 (SOE) 为目标.所有工作站都相似或相同，具有相同的防病毒解决方案.这显然意味着目标计算机处于比正常状态更加统一的状态.任何防病毒问题都将被检测到并可以进行管理.就我个人而言，我还没有看到针对此类包部署的简单脚本存在任何重大的防病毒干扰问题.
  • 在打包团队中往往有很多脚本调试方面的专业知识，但 C++ 知识却很少(尽管很多人知道一些 C# 和 PowerShell).开发人员可能更喜欢 C#，但可以轻松处理脚本.
  • For me PowerShell is at the time of writing absolutely the worst choice. It is both managed code (unreliable runtime) and a script custom action (poor debugging).
  • I would like to write C# / DTF custom actions like Chris does for simplicity, but I don't believe the time is ripe - the runtime environment cannot be guaranteed. In the real world you don't throw out a working C++ dll in favor of a C# dll. It is a huge reliability downgrade.
  • C++ dll and Installscript are the only choices for making a professional, vendor setup targeting diverse computers (not standardized desktops in managed environments - corporations, but computers anywhere in the world in all their heterogeneous states, in different languages and diverse hardware and software configurations).
  • A C++ custom action dll is significantly harder to set up and configure than other custom actions with its exports, build settings and outputs, but it is no magical impossibility. In return you get a lot: full debugging capability, advanced language features and error handling. And the big one: minimum dependencies (make sure you enable static linking to eliminate all possible dependencies). For debugging you can simply attach the Visual Studio debugger to a message box displayed by your custom action, and then you can step through code. This works for both user and system context custom actions. Full control. This actually makes debugging a C++ custom action easier than a script custom action, and certainly more reliable.
  • JavaScript I would generally avoid. It just isn't a complete language. I still think it is more reliable than managed code though - in terms of runtime dependencies and reliability (fewer runtime dependency pitfalls).
  • VB Script is acceptable for "internal corporate use" in a managed environment. I would never use it for a vendor setup for general distribution. But to distribute packages on a corporate network it can be used. Both for developers packaging their own applications, and for application packagers tweaking third party setups for corporate deployment. The primary advantages and disadvantages of VBScript actions:
    • As stated above, scripts should only be used in rare cases, and a win32 C++ dll or WiX's custom action dll should be used for all common scripting tasks that people tend to re-use. Scripts are only to be used when needed to get the job done.
    • VBScript custom actions are, like all script custom actions, in general hard to debug, vulnerable to anti-virus interference and lacking in language features needed to implement advanced coding constructs. You just don't have the language features and flexibility available with C++ (now even C++ custom actions can be blocked by security software - but it is not as common, but could that change as security is tightened?)
    • Scripts are transparent for everyone (both purpose and implementation) and can be debugged and maintained easily by several team members with work handed off between them. All can see what is going on and everyone can pick up someone else's work quickly.
    • The source embedded in the MSI is the right source, you don't need to maintain source files separately in a repository to compile it like you need for managed code (C#). For application packaging source control is rarely set up is my experience (it should be though).
    • Corporate packages target a standard operating environment (SOE). All the workstations are similar or the same, with the same anti-virus solution. This obviously means that the target computers are in a much more uniform state than what is normal. Any anti-virus issues will be detected and can be managed. Personally I haven't seen any major anti-virus interference problems with simple scripts for such package deployment.
    • There tends to be a lot of expertise in script debugging in packaging teams, but very little C++ knowledge (many know some C# and PowerShell though). Developers would likely prefer C#, but can easily handle scripts.

    我可以肯定的一点是，托管代码自定义操作的可用性将导致人们在他们的设置中做太多不应该在设置中完成的事情(丰富的 API，相对容易编码).这一切都是因为编码更容易、更快，而有问题的开发人员可能不了解应该如何进行正确的部署.这不可避免地导致过度使用各种自定义操作，进而导致主要的部署问题，如 自定义操作的复杂性会触发意外错误.

    One thing that I am certain of, is that the availability of managed code custom actions will cause people to do way too many things in their setups that should never be done in a setup (rich API, relatively easy coding). This is all because coding is easier and faster, and the developer in question may lack an understanding of how proper deployment should be done. This inevitably leads to overuse of custom actions of all kinds, and in turn major deployment problems as the complexity of custom actions trigger unexpected errors.

    这篇关于Windows 安装程序在 Win 10 上失败，但在使用 WIX 的 Win 7 上失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！