C++ Binary Compatibility and Pain-Free Upgrades to Visual Studio 2019

Marian Luparu

January 31st, 20196 0

Visual Studio 2019 pushes the boundaries of individual and team productivity. We hope that you will find these new capabilities compelling and start your upgrade to Visual Studio 2019 soon.

As you are considering this upgrade, rest assured that Visual Studio 2019 makes it distinctively easy to move your codebase from previous versions of Visual Studio. This post captures the reasons why your upgrade to Visual Studio 2019 will be pain-free.

You can install the latest IDE side-by-side with any older VS versions
You can continue building your C++ code with the MSVC v140 (VS 2015.3) or v141 (VS 2017) toolsets
You can upgrade to the latest MSVC v142 (VS 2019) and maintain binary compatibility with any of your 3rd party libraries that haven’t migrated yet
Regardless of the toolset you’re on, you get access to the full collection of OSS libraries available in Vcpkg

Side-by-side Visual Studio Installations

You can install the latest version of Visual Studio on a computer that already has an earlier version installed and continue to use both versions in parallel with no interference. This is a great way to try Visual Studio 2019 or adopt it for some of your projects. The Visual Studio Installer will let you manage installations of Visual Studio 2017 and 2019 from a central UI.

MSVC v140 (VS 2015.3) and MSVC v141 (VS 2017) Toolsets in the Visual Studio 2019 IDE

Even if you are not ready yet to move your project to the latest toolset (MSVC v142), you can still load your project in the Visual Studio 2019 IDE and continue to use your current older toolset.

Loading your existing C++ projects into the IDE will not upgrade/change your project files. This way, your projects also load in the previous version of the IDE in case you need to go back or you have teammates that have not yet upgraded to VS 2019 (this functionality is also known as project round-tripping).

Toolsets from older VS installations on your box are visible as platform toolsets in the latest IDE. And if you are starting fresh with only VS 2019 installed on your machine, it is very easy to acquire these older toolsets directly from the Visual Studio Installer by customizing the C++ Desktop workload (with the Individual Components tab listing all the options).

New v142 toolset now available

Within the Visual Studio 2019 wave (previews, its general availability, and future updates), we plan to continue evolving our C++ compilers and libraries with

new C++20 features,
faster build throughput, and
even better codegen optimizations.

The MSVC v142 toolset is now available and it already brings several incentives for you to migrate.

VC Runtime in the latest MSVC v142 toolset is binary compatible with v140 and v141

We heard it loud and clear that a major reason contributing to MSVC v141’s fast adoption today is its binary compatibility with MSVC v140. This allowed you to migrate your own code to the v141 toolset at your own pace, without having to wait for any of your 3rd party library dependencies to migrate first.

We want to keep the momentum going and make sure that you have a similarly successful adoption experience with MSVC v142 too. This is why we’re announcing today that our team is committed to provide binary compatibility for MSVC v142 with both MSVC v141 and v140.

This means that if you compile all your code with the v142 toolset but still have one or more libraries that are built with the v140 or v141 toolset, linking all of it together (with the latest linker) will work as expected. To make this possible, VC Runtime does not change its major version in VS 2019 and remains backward compatible with previous VC Runtime versions.

C:\source\repos\TimerApp\Debug>dumpbin TimerApp2019.exe /IMPORTS | findstr .dll
mfc140ud.dll
KERNEL32.dll
USER32.dll
GDI32.dll
COMCTL32.dll
OLEAUT32.dll
gdiplus.dll
VCRUNTIME140D.dll
ucrtbased.dll
       2EE _seh_filter_dll

When you mix binaries built with different supported versions of the MSVC toolset, there is a version requirement for the VCRedist that you redistribute with your app. Specifically, the VCRedist can’t be older than any of the toolset versions used to build your app.

Hundreds of C++ libraries on Vcpkg are available regardless of the toolset you’re using

If you are using Vcpkg today with VS 2015 or VS 2017 for one or more of your open-source dependencies, you will be happy to learn that these libraries (close to 900 at the time of this writing) can now be compiled with the MSVC v142 toolset and are available for consumption in Visual Studio 2019 projects.

If you are just getting started with Vcpkg, no worries – Vcpkg is an open-source project from Microsoft to help simplify the acquisition and building of open-source C++ libraries on Windows, Linux, and Mac.

Because v142 is binary compatible with v141 and v140, all the packages you’ve already installed will also continue to work in VS 2019 without recompilation; however, we do recommend recompiling when you can so that you can enjoy the new compiler optimizations we’ve added to v142!

If you have VS 2019 Preview installed side-by-side with an older version of VS (e.g. VS 2017), Vcpkg will prefer the stable release, so you will need to set Vcpkg’s triplet variable VCPKG_PLATFORM_TOOLSET to v142 to use the latest MSVC toolset.

MSVC compiler version changes to 19.2x (from 19.1x in MSVC v141)

Last but not least, the compiler part of the MSVC v142 toolset changes its version to 19.20 – only a minor version increment compared with MSVC v141.

Note that feature-test macros are supported in the MSVC compiler and STL starting with MSVC v141 and they should be the preferred option to enable your code to support multiple MSVC versions.

Call to action

Please download Visual Studio 2019 today and let us know what you think. Our goal is to make your transition to VS 2019 as easy as possible so, as always, we are very interested in your feedback. We can be reached via the comments below or via email (visualcpp@microsoft.com). If you encounter other problems with Visual Studio or MSVC or have a suggestion please let us know through Help > Send Feedback > Report A Problem / Provide a Suggestion in the product, or via Developer Community. You can also find us on Twitter at @VisualC.

Marian Luparu Group Product Mgr, Microsoft C++ Team

6 comments

Ulysses February 24, 2019 2:23 pm 0

Hey Microsoft, thanks for nuking all the comments when you reopened under devblogs.microsoft.com. Let me reiterate that a good number of us are disappointed that you did a 180 with your choice to preserve compatibility. “The next major release” of VS was gonna be the one to introduce important breaking changes such as EBO and bugfixes. You already have switchable toolsets. It’s already easy for library authors to catch up. It’s already possible for vcpkg ports to massage things. But no, let us all suffer from stifled innovation for another major cycle. Way to go, Microsoft.

Tsahi Asher February 28, 2019 7:50 am 0

I don’t get why Side by Side is a thing now. It existed since ever in previous versions of Visual Studio.

Me Gusta March 12, 2019 4:18 am 0

I think it would be a good idea to list the things that preserving compatibility would get in the way of.
For example, is the long running problem of:
error LNK2001: unresolved external symbol “__declspec(dllimport) public: static class std::locale::id std::codecvt<char16_t,char,struct _Mbstatet>::id” (__imp_?id@?$codecvt@_SDU_Mbstatet@@@std@@2V0locale@2@A)
error LNK2001: unresolved external symbol “__declspec(dllimport) public: static class std::locale::id std::codecvt<char32_t,char,struct _Mbstatet>::id” (__imp_?id@?$codecvt@_UDU_Mbstatet@@@std@@2V0locale@2@A)
Meaning that it is hard to implement anything that uses char16_t and char32_t somehow linked to the binary compatibility? I ask this because if it is then you are actively getting in the way of standards conforming code, and you are supposed to be striving towards standards conformance, right?

freudi freudi May 2, 2019 8:12 am 0

I just let VS2019 update one project to toolset 142, now I get an error C1047 from a lib build with toolset 141. If I changed back to 141 C1047 is gone. So I may misunderstand your blog, should’nt it work ? Linking a 142 Toolset project to a 141 lib ?

Paul Ceccato May 6, 2020 5:05 am 0

Does this backwards binary compatibility work with x64 Release builds?

I’m trying to link a v141 x64 release library with a v142 x64 release project and I get the following error:

1>LINK : fatal error C1047: The object or library file ‘..\x64\lib\blah.lib’ was created with an older compiler than other objects; rebuild old objects and libraries.

release x86 and debug x64 seems to be okay.

Paul Ceccato May 6, 2020 6:30 am 0

it seems you have to disable whole program optimization for binary compatibility to work.

Discussion is closed. Login to edit/delete existing comments.

Ulysses February 24, 2019 2:23 pm 0

Hey Microsoft, thanks for nuking all the comments when you reopened under devblogs.microsoft.com. Let me reiterate that a good number of us are disappointed that you did a 180 with your choice to preserve compatibility. “The next major release” of VS was gonna be the one to introduce important breaking changes such as EBO and bugfixes. You already have switchable toolsets. It’s already easy for library authors to catch up. It’s already possible for vcpkg ports to massage things. But no, let us all suffer from stifled innovation for another major cycle. Way to go, Microsoft.
Tsahi Asher February 28, 2019 7:50 am 0

I don’t get why Side by Side is a thing now. It existed since ever in previous versions of Visual Studio.
Me Gusta March 12, 2019 4:18 am 0

I think it would be a good idea to list the things that preserving compatibility would get in the way of.
For example, is the long running problem of:
error LNK2001: unresolved external symbol “__declspec(dllimport) public: static class std::locale::id std::codecvt<char16_t,char,struct _Mbstatet>::id” (__imp_?id@?$codecvt@_SDU_Mbstatet@@@std@@2V0locale@2@A)
error LNK2001: unresolved external symbol “__declspec(dllimport) public: static class std::locale::id std::codecvt<char32_t,char,struct _Mbstatet>::id” (__imp_?id@?$codecvt@_UDU_Mbstatet@@@std@@2V0locale@2@A)
Meaning that it is hard to implement anything that uses char16_t and char32_t somehow linked to the binary compatibility? I ask this because if it is then you are actively getting in the way of standards conforming code, and you are supposed to be striving towards standards conformance, right?
freudi freudi May 2, 2019 8:12 am 0

I just let VS2019 update one project to toolset 142, now I get an error C1047 from a lib build with toolset 141. If I changed back to 141 C1047 is gone. So I may misunderstand your blog, should’nt it work ? Linking a 142 Toolset project to a 141 lib ?
Paul Ceccato May 6, 2020 5:05 am 0

Does this backwards binary compatibility work with x64 Release builds?

I’m trying to link a v141 x64 release library with a v142 x64 release project and I get the following error:

1>LINK : fatal error C1047: The object or library file ‘..\x64\lib\blah.lib’ was created with an older compiler than other objects; rebuild old objects and libraries.

release x86 and debug x64 seems to be okay.
- Paul Ceccato May 6, 2020 6:30 am 0
  
  it seems you have to disable whole program optimization for binary compatibility to work.