关于“Visual Studio 2015 和 Visual Studio 2017 之间的二进制兼容性"的问题 [英] Questions about "Binary Compatibility between Visual Studio 2015 and Visual Studio 2017"

问题描述

https:///docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2017 表示保证 Visual Studio 2015 和 Visual Studio 2017 之间的 C++ 二进制兼容性，除了:

https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2017 says that C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2017 is guaranteed except:

1)当使用/GL 编译器开关编译静态库或目标文件时.

1)When static libraries or object files are compiled with the /GL compiler switch.

2) 使用使用工具集构建的库时，该工具集的版本高于用于编译和链接应用程序的工具集.例如，使用编译器版本 19.12 编译和链接的程序可以使用使用 19.0 到 19.12 编译的库.此外，二进制兼容性仅存在于 Visual Studio 2015 和 Visual Studio 2017 之间；不支持将 19.x 程序与 Visual Studio 2013 或更早版本生成的库链接.

2)When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with compiler version 19.12 can consume libraries that are compiled with 19.0 up through 19.12. Also, binary compatibility only exists between Visual Studio 2015 and Visual Studio 2017; linking 19.x programs with libraries produced by Visual Studio 2013 or earlier is not supported.

例外 2 让我感到困惑.为什么在这种情况下不能保证二进制兼容性?

Exception 2 makes me confused. Why binary compatibility can not be guaranteed in this case?

让我们说得更具体一点.提供了一个文件夹，其中包含自定义 exe、自定义 dll 和 vc_toolset dll(v140 或 v141)的一部分.自定义 exe 和自定义 dll 都动态链接到 vc_toolset dll 的一部分，其中包括 CRT dll、msvcp140.dll、vcruntime140.dll.此外，/GL 选项未启用.

Let's make it be more specific. Provided a folder which contains a custom exe, a custom dll and part of vc_toolset dlls(v140 or v141). Both the custom exe and the custom dll are linked dynamically to part of vc_toolset dlls which includes CRT dlls, msvcp140.dll, vcruntime140.dll. Besides, /GL option is not enabled.

我在下面列出了几种组合.我想知道每个人的二进制兼容性.

I list several combinations below. I wonder each one's binary compatibility.

1)vs2015构建的exe+vs2015构建的dll+vs2015的v140工具集dll

我认为在这种情况下可以保证二进制兼容性.

2)vs2015构建的exe+vs2015构建的dll+vs2017的v141工具集dll

基于案例 1，另外，工具集 dll 被替换为 vs2017 随附的较新版本.

另外，我认为在这种情况下可以保证二进制兼容性.

3)由 vs2015 构建的 exe + dll 由 vs2017 重建 + vs2015 的 v140 工具集 dll

3)exe built by vs2015 + dll rebuilt by vs2017 + v140 toolset dlls of vs2015

基于案例1，使用vs2017重建自定义dll.那么有两个选择:

a) 只替换 dll，不会使用新 dll 的导入库重建 exe

b) 替换 dll 并使用新 dll 的导入库重建 exe.

根据上述链接的例外 2，在 a) 和 b) 情况下无法保证二进制兼容性.但为什么 ?自定义dll的所有接口和依赖都没有改变，也没有依赖v141的新特性.

4)由 vs2015 构建的 exe + dll 由 vs2017 重建 + vs2017 的 v141 工具集 dll

4)exe built by vs2015 + dll rebuilt by vs2017 + v141 toolset dlls of vs2017

基于案例 3，另外，工具集 dll 被替换为 vs2017 随附的较新版本.

5)exe rebuilt vs2017 + vs2015构建的dll + vs2015的v140工具集dll

5)exe rebuilt by vs2017 + dll built by vs2015 + v140 toolset dlls of vs2015

基于案例1，自定义exe使用vs2017重建，并与之前vs2015构建的自定义dll的导入库链接

根据上面的链接，我认为在这种情况下可以保证二进制兼容性.

6)exe rebuilt vs2017 + vs2015构建的dll + vs2017的v141工具集dll

6)exe rebuilt by vs2017 + dll built by vs2015 + v141 toolset dlls of vs2017

基于案例 5，另外，工具集 dll 被替换为 vs2017 附带的较新版本.如果情况5和情况2可以保证，我认为在这种情况下也是可以保证的.

我的理解正确吗?

推荐答案

既然你明确调用了

... CRT DLL ...

... CRT DLLs ...

我会回答那部分:

VS2017 CRT 和 VS2015 CRT 之间的向后兼容性是 100% 保证的！(当然是模 MS 错误.)

Backwards Compatibility between the VS2017 CRT and the VS2015 CRT is 100% guaranteed! (Modulo MS Bugs of course.)

我该怎么说?MSVC CRT 的默认部署方法是将所有 CRT 文件部署到 System32，因此大多数应用程序将使用一 (1) 组全局 CRT DLL._{(至少 AFAIKT，许多应用程序都使用 DLL 形式的 MS CRT，但并未将所有 CRT DLL 捆绑在其应用程序目录中.)}

How can I say this? The default deployment method for the MSVC CRT is deploying all CRT files to System32, so there is one (1) global set of CRT DLLs that most applications will use. _{(At least AFAIKT, many many apps use the MS CRT in DLL form, but do not bundle all CRT DLLs in their app directory.)}

与 VS 2017 和 2015 相比，所有 CRT DLL 都具有相同的文件名，即 msvcp140.dll、vcruntime140.dll，没有 141 文件！(所以 Bullet Point 6 不存在.)

And with VS 2017 vs. 2015, all CRT DLLs have the same filenames, i.e. msvcp140.dll, vcruntime140.dll, there are no 141 files! (So Bullet Point 6 does not exist.)

因此，给定的 Windows 系统最多可以拥有一组全局 CRT140 文件，并且由于没有应用程序控制这一点，因此新版本的 CRT140 必须向后兼容针对旧版本构建的应用程序.

So a given Windows system can have at most one global set of CRT140 files, and since no application controls this, newer versions of CRT140 must be backwards compatible to apps built against older versions.

鉴于此，我将简单地不做情况3和5(关于CRT)来自您的问题:始终部署最新您的组件所依赖的 MS CRT.

Given that, I would simply not do cases 3 and 5 (with regard to CRT) from your question: Always deploy the newest MS CRT that your components rely upon.

甚至发现了一个博客条目wrt.这个(2017/03/07):

Even found a blog entry wrt. this (2017/03/07):

... VCRedist 仅向后兼容，因此您需要将 VS 2017 中可用的最新 VCRedist 140 与您的应用程序一起重新分发....

... The VCRedist is only backward compatible, so you will need to redistribute the latest VCRedist 140 available in VS 2017 with your app. ...

<小时>

关于要点3和4的情况2015.exe <->2017.dll我创建了一个新问题:VS2017 和 VS2015 应用程序与 dll 之间的官方二进制不兼容是否准确? 因为这真的很奇怪，恕我直言.

---

With regard to the bullet point 3 and 4 situation 2015.exe <-> 2017.dllI have created a new question: Is the official binary incompatibility between VS2017 and VS2015 app vs. dll accurate? because this is really weird, IMHO.

这篇关于关于“Visual Studio 2015 和 Visual Studio 2017 之间的二进制兼容性"的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！