关于“Visual Studio 2015 和 Visual Studio 2017 之间的二进制兼容性”的问题

https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2017 https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2017表示保证 Visual Studio 2015 和 Visual Studio 2017 之间的 C++ 二进制兼容性，但以下情况除外：

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

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

例外2让我很困惑。为什么在这种情况下不能保证二进制兼容性呢？

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

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

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

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

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

基于案例 1，此外，工具集 dll 已替换为 vs2017 附带的较新版本。

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

3）vs2015+dll构建的exerebuilt通过 vs2017 + vs2015 的 v140 工具集 dll

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

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

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

根据上面链接的例外2，在a）和b）情况下不能保证二进制兼容性。但为什么 ？自定义dll的所有接口和依赖项均未更改，并且不依赖于v141的新功能。

4）vs2015+dll构建的exerebuilt通过 vs2017 + vs2017 的 v141 工具集 dll

此外，基于案例 3，工具集 dll 已替换为 vs2017 附带的较新版本。

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

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

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

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

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

我的理解正确吗？

既然你明确地调用了

... CRT DLL ...

我将回答这部分：

VS2017 CRT 和 VS2015 CRT 之间的向后兼容性得到 100% 保证！ （当然是模数 MS Bug。）

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 都有相同的文件名, i.e. msvcp140.dll, vcruntime140.dll，没有141文件！ （所以要点6不存在。）

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

鉴于此，我会简单地not do cases 3 and 5（关于 CRT）来自你的问题：始终部署newest您的组件所依赖的 MS CRT。

甚至发现了一个博客条目。这 https://blogs.msdn.microsoft.com/vcblog/2017/03/07/binary-compatibility-and-pain-free-upgrade-why-moving-to-visual-studio-2017-is-almost-too-easy/(2017/03/07):

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

关于第3点和第4点的情况2015.exe <-> 2017.dll我创建了一个新问题：VS2017 和 VS2015 应用程序与 dll 之间的官方二进制不兼容性是否准确？ https://stackoverflow.com/questions/53187152/is-the-official-binary-incompatibility-between-vs2017-and-vs2015-app-vs-dll-acc因为这真的很奇怪，恕我直言。