[StephanTLavavej]

MSVC STL dev here. We're doing something different this time around. VS 2015 RTM and Update 1/2/3 were binary-compatible (as usual) while adding lots of features to the compiler and STL (unusual). VS 2017 RTM and its Updates will continue to be binary-compatible while adding features, meaning that our DLLs are still vcruntime140.dll, msvcp140.dll, etc. The versions are admittedly a mess, so here's the magic decoder ring:

VS 2015: IDE version 14, DLL version 140, toolset version 140, compiler version 19.0 (the C++ compiler is older than the Visual part of Visual C++). VS 2017: IDE version 15, DLL version 140 (same!), toolset version 141, compiler version 19.1

We still recommend that you build everything with VS 2017 consistently, as this will give you the most performance and correctness. However, you can mix in object files, static libraries, and DLLs compiled with previous versions all the way back to 2015 RTM, and things will continue to work (although you won't necessarily activate fixes in the newer version).

For more info, read the comments on https://blogs.msdn.microsoft.com/vcblog/2016/08/24/c1417-fea... where I mentioned WCFB02.

[wmkn]

Thank you. I seem to have completely missed all the VC blog posts about the bincompat decision with regard to Visual Studio "15"/2017.

Glad to know that the VC100 to VC140 overhaul that I completed only very recently can still be considered fully up to date with the latest and greatest :).

[StephanTLavavej]

Yeah, it makes migrating a codebase with third-party libraries built with older toolsets easier. Note that you'll need to build with VS 2017 if you want header-only improvements like the vector overhaul, and you'll need to update to 2017's VCRedist if you want DLL improvements (e.g. if you're still on 2015 RTM's msvcp DLL, you don't have the iostreams correctness/performance fix that shipped in 2015 Update 2; DLL improvements are uncommon but they do happen).