VS2017 和 Win7/XP 上缺少“api-ms-win-core-rtlsupport-l1-2-0.dll”答案

【问题标题】：VS2017 and missing "api-ms-win-core-rtlsupport-l1-2-0.dll" on Win7/XPVS2017 和 Win7/XP 上缺少“api-ms-win-core-rtlsupport-l1-2-0.dll”
【发布时间】：2018-01-26 11:20:21
【问题描述】：

在将我的一些程序从 VS2015 移植到 VS2017 后，注意到这些二进制文件不再在 Windows 7 或 Windows XP 上运行——即使它们是使用 v141_xp 工具集编译的。程序无法启动，缺少 DLL api-ms-win-core-rtlsupport-l1-2-0.dll（注意 2）。

我很清楚那些api-ms-win-* DLL 属于 UCRT，并且从 VS2015 开始，我必须从 Windows 10 SDK 重新分发 UCRT DLL（可在 Windows 10 SDK 中的Redist\ucrt\DLLs 找到目录）以及我的应用程序 - 仅重新分发 vcruntime140.dll 和 msvcp140.dll 是不够足够的。但是我的 Windows SDK 目录中只有api-ms-win-core-rtlsupport-l1-1-0.dll，但没有 api-ms-win-core-rtlsupport-l1-2-0.dll。为了确定，我刚刚下载并重新安装了最新的 Windows SDK (10.0.15063)。有问题的 DLL 仍然不存在！

我还尝试通过VC_redist.x86.exe 在 Windows 7（或 XP）机器上安装 VS2017 Redistributable 软件包 - 从 Visual Studio 网站 (14.11.25325) 下载的最新版本。显然，这会将api-ms-win-* DLL 复制到“System32”目录中。但是，同样，只有api-ms-win-core-rtlsupport-l1-1-0.dll，但不是 api-ms-win-core-rtlsupport-l1-2-0.dll。应用仍然无法启动。

[编辑]

这当然只适用于我链接到 DLL 运行时 (/MD)。如果我链接到“静态”运行时 (/MT)，我会得到一个二进制文件，它在 UCRT 上没有 DLL 依赖项，并且在 Windows 7 和 XP 上运行良好。

[编辑#2]

混乱的解决方法请参考我的另一篇帖子（包括编辑）：
https://stackoverflow.com/a/45773325/1766377

【问题讨论】：

最好是为XP创建额外的项目配置，在VM中安装旧版本的VS并通过旧版本的VS编译xp项目文件。
我已经在我的项目配置中选择了v141_xp 工具集 - 它专门针对 Windows XP。在 VS2015 中，使用 v140_xp 工具集非常适合为 Windows XP 创建二进制文件 - 只要我重新分发 Windows 10 SDK 中的 vcruntime140.dll 和 msvcp140.dll 以及 api-ms-win-* UCRT DLL。但似乎 VS2017 现在正在链接到较新的 UCRT 版本，所需的可再发行组件（尚未）可用 - 无论是在 Windows 10 SDK 中还是通过 VS2017 可再发行安装程序 - 这对我来说似乎是一个错误......
我了解您的问题。这就是为什么使用旧版本的 VS 编译 XP exe 的原因
我可以在较旧的 VS 版本（例如 VS2015）上使用它来生成可在 Windows 7 或 Windows XP 上运行的二进制文件，这不是的重点。关键是 - 据我所知 - VS2017 应该生成适用于 Windows 7 的二进制文件（以及在选择 v141'_xp 工具集时也适用于 Windows XP），但显然无法做到所以！或者，更具体地说，M$ 似乎没有在其当前的 Windows SDK 中为这些平台提供正确的可再发行 DLL。

标签： c++ visual-studio windows-7 visual-studio-2017 windows-xp

【解决方案1】：

在项目的属性页中，尝试将 Windows SDK 版本从 10.0.15063.0 更改为 10.0.10240.0。我认为这将解决它，前提是您的构建机器上安装了较旧的 SDK。要尝试的其他方法是将平台工具集更改为 v140_xp。 VS 2017 然后使用 VS 2015 工具链构建，前提是安装了 VS 2015。

我个人的偏好是通过与静态运行时链接来避免任何“DLL 地狱”，尽管如果 exe 和 dll 需要共享一个堆并且如果您正在构建多个二进制文件（我只有两个）。

【讨论】：

您是指“常规”页面上的“Windows SDK 版本”选项吗？我已经将它设置为 "7.0"，我认为这是v141_xp 工具集所必需的（并自动应用！）。此外，正如您在我发布的 Dependency Walker 屏幕截图中所见：对 api-ms-win-core-rtlsupport-l1-2-0.dll 的依赖（注意 2）源自 VS2017 VCRUNTIME140.DLL 的化身。而且那个 DLL 根本不会改变，无论我如何构建自己的可执行文件，我认为...
啊，有趣，我错过了，抱歉，太可怕了，如果不是，它应该被称为 VCRUNTIME141.DLL，是的，这就是我的意思。我认为使用 v140_xp 工具集构建并使用 VS 2015 可再发行组件是您唯一的选择，尽管这样您会失去最新的编译器功能。真是一团糟。
我没有足够的代表来评论你的新帖子，所以我会在这里发表评论。也许某个好心的版主会移动它。无论如何，我不认为您提到的两个目录是可再发行包的不同“年份”。版本 14.11.25415 将所有内容都放在一个“onecore”文件夹中，因为它给您带来了很多麻烦，可能不是您想要的，请参阅：link
谢谢！因此，onecore 中的 DLL 似乎是针对 unified Desktiop/Mobile/IoT 平台（又名“OneCore”）而不是我们应该正常重新分配的桌面应用程序。我认为目录结构相当混乱！他们应该称它为Redist\desktop\<version> 和Redist\onecore\<version>，而不是把版本号放在first - 这意味着它只是同一事物的两个版本 - 但事实并非如此。可以避免我的一些头痛......
类似的东西，都非常不清楚。我仍然有 VS 2017 15.2，我的两个 Redist 文件夹是 14.10.25008 和 14.10.25017，后者是 onecore（仅），前者是相反的，但在 Tools 文件夹下（导致 include、lib 和相关文件夹）我只有 14.10.25017，在 lib 下有一个 onecore 文件夹。不同的工具和 Redist 版本感觉不对，但如果“较旧”的可再发行组件工作，那么我想没关系。不过，我会向 Microsoft 提交错误报告。您最初观察到（onecore）可再发行文件中似乎缺少文件似乎是有效的。

【解决方案2】：

好的，这很有趣：刚刚我的 VS2017 发现了一个新的更新。显然，我的 VS2017 从 v15.2 更新到了 v15.3.1。运行时库似乎也更新了！

我的 VS2017 安装目录中现在有两个目录，VC\Redist\MSVC\14.11.25325 和 VC\Redist\MSVC\14.11.25415。 vcruntime140.dll 存在于两个目录中。但是较新的版本（25415，右）与旧版本（25325，左）相比具有完全不同的依赖关系：

只有“新”版本具有 Windows 7 上缺少的依赖项。所以，我应该可以使用“旧”版本。但这意味着我被锁定到“旧”版本。这是正常的/有意的？？？

（顺便说一句：VS2017 v15.3.1 的两个 DLL 版本都比我最初从 v15.2 获得的版本更新）

[编辑]

所以，我刚刚注意到VC\Redist\MSVC\14.11.25325 和 VC\Redist\MSVC\14.11.25415 目录之间存在微妙的区别： 25415 目录在另一个名为onecore 的子文件夹中包含所有DLL 文件，而另一个没有。显然，这意味着“较新”的 DLL 版本（带有onecore 子文件夹的版本）不应该与普通桌面应用程序一起重新分发；它们严格用于“OneCore”移动/物联网平台。

结论：
M$ 在设计 Redist 目录结构方面做得很好尽可能地混乱。将“normal”和“onecore”可再发行组件的版本号放在目录层次结构的同一级别（而不是在 那个上拥有单独的 onecore 和 desktop 目录em> level) 表示这些目录代表同一事物的不同版本 - 根本不是这种情况：-/

不要不将任何`/onecore/` DLL 与普通桌面应用程序一起分发！

【讨论】：

不要*不*将任何*/onecore/* DLL 与普通桌面应用程序一起分发！

不要不将任何`/onecore/` DLL 与普通桌面应用程序一起分发！