所以，我知道 Microsoft 增强了他们的工具集，以便在使用 VS2015、VS2017 和 VS2019 构建的应用程序和库之间存在兼容性。
但是，我认为这种组合会失败： 使用 VS2012 (VC11) 的工具集构建的 C++ 应用程序 (.exe)，在运行时与 包含使用 VS2019 工具集构建的 C++ 的共享库 (.dll)
但是，我们已经看到这种组合“似乎”有效。
我预计这种组合会失败，但无法解释它的成功。 有人对此有任何想法吗？
答案 0 :(得分：2)
VS 2015 Update 3、VS 2017 和 VS 2019 之间 Microsoft Docs 中涵盖的“二进制兼容性”专门围绕标准 C++ 库和静态库链接。从历史上看，不同代的工具集在运行时无法链接或崩溃。为避免崩溃，VS 添加了这些符号，因此您会在链接时收到错误：
error LNK2038: mismatch detected for '_MSC_VER': value '1600' doesn't match value '1700' in CppFile1.obj
VS 2015 Update 3、VS 2017 和 VS 2019 都使用“1900”作为链接标记，因为它们经过设计和测试可以在混合时工作。当然，重要的是要注意最终链接预计将针对较新的 CRT 库和链接器（即仅向前兼容）。链接戳仅在使用 C++ 标头时被拉入，而不是 C 标头或 Win32 系统标头。
<块引用>例如，如果您有一个 C++ 库，该库具有处理类实现中的 std::vector 的内联函数，并且类的其余部分托管在 DLL 中，那么从历史上看，如果您使用不同的工具集，因为 std::vector 的实现将使用不同的二进制布局等。这是在工具集之间拥有这种“二进制兼容性”策略的关键价值，因此可以更轻松地使用最新的工具集并保留大部分现有的第 3 方库和工具。
通过导入库的 C ABI 始终适用于不同的编译器版本。这在很大程度上是 Win32 API 和 COM API 托管在 DLL 中并使用 C ABI 的原因。否则，编译器工具集的每个版本都需要一组新的操作系统库。理论上，您可以使用旧平台 SDK 之一中提供的库成功地将程序与 VS 2019 链接。
所以这真的取决于你的 exe 正在使用什么。如果它只是使用 C API、extern "C" 链接和/或 Win32 API，无论您使用什么组合，它都可以正常工作。
TL;DR：使用 C ABI 的动态链接库跨工具集工作。静态库或带有 C++ ABI 的库只能在特定场景下跨工具集工作。
<块引用>这里还有一个警告：整个程序优化/链接时代码生成静态库在工具集之间不兼容。