This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 28.000000000000004%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESK%3C/text%3E%3C/svg%3E)
The MSDN documentation says that you need to use the Runtime version that correpsonds to the Platform Toolset version, otherwise it leads to UB.
I have a legacy project that was migrated to Visual Studio 2019, and has a <PlatformToolset>v142</PlatformToolset> but <Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">.
I know that there should be ToolsVersion="Current" or ToolsVersion="16.0" which is generated by CMake.
I get no warnings from Visual Studio when building the project, but I am concerned if specifing incompatible versions will lead to linking the wrong CRT version.
When I build with /MD it seems that everything is ok:
Image has the following dependencies:
msi.dll
MSVCP140D.dll
VCRUNTIME140D.dll
VCRUNTIME140_1D.dll
ucrtbased.dll
KERNEL32.dll
But the legacy project uses /MT and I can't determine which CRT is used from the dumpbin output for .obj file:
Linker Directives
-----------------
/FAILIFMISMATCH:_MSC_VER=1900
/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2
/FAILIFMISMATCH:RuntimeLibrary=MTd_StaticDebug
/DEFAULTLIB:libcpmtd
/FAILIFMISMATCH:_CRT_STDIO_ISO_WIDE_SPECIFIERS=0
/DEFAULTLIB:uuid.lib
/DEFAULTLIB:uuid.lib
/DEFAULTLIB:LIBCMTD
/DEFAULTLIB:OLDNAMES
Is ToolsVersion even meaningfull and can it lead to linking the wrong CRT version?
How can I inspect which version of Runtime is linked when compiled with /MT?
According to the documentation of the Project Element at https://learn.microsoft.com/en-us/visualstudio/msbuild/project-element-msbuild?view=vs-2022 ToolsVersion is an optional attribute that refers to "The version of the Toolset MSBuild uses to determine the values for $(MSBuildBinPath) and $(MSBuildToolsPath)". Drilling down further into the documentation of MSBuild Reserved and Well-known properties at https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-reserved-and-well-known-properties?view=vs-2022 $(MSBuildBinPath) is for "The absolute path of the folder where the MSBuild binaries that are currently being used are located (for example, C:\Windows\Microsoft.Net\Framework\<versionNumber>). This property is useful if you have to refer to files in the MSBuild directory." and $(MSBuildToolsPath) is for "The installation path of the MSBuild version that's associated with the value of MSBuildToolsVersion."
So my understanding from this documentation is that ToolsVersion is not related to the C/C++ runtime.
From the page about binary compatibility: https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170
You can mix binaries built by different versions of the v140, v141, v142, and v143 toolsets. However, you must link by using a toolset at least as recent as the most recent binary in your app. Here's an example: you can link an app compiled using any 2017 toolset (v141, versions 15.0 through 15.9) to a static library compiled using, say, Visual Studio 2019 version 16.2 (v142). You just have to link them by using a version 16.2 or later toolset. You can link a version 16.2 library to a version 16.4 app as long as you use a 16.4 or later toolset.
So my concern is that the toolset version that would be used for linkage might be invalid. That it might result in linking "16.4 app with 16.2 library using 16.2 toolset".
In my particular case I'm afraid that some libraries might be built with a 4.0 version Toolset as it is specified in the project file (which is incompatible with v140 and later, if I understood correctly).
How can I inspect what $(MSBuildBinPath) has been evaluated to during msbuild.exe invocation?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(86.4, 25%, 18%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAB%3C/text%3E%3C/svg%3E)
You can configure msbuild logging to log the full commands used to compile and link your code. Look for the mention of cl.exe (MSVC), or msbuild.exe ,their full path will be shown.
You can invoke the executable yourself with the path shown in the logs to find it's version.
Note that version of cl.exe may not share the prefix with MSBuild version or Visual Studio version.
Ref: https://learn.microsoft.com/en-us/visualstudio/msbuild/logging-in-msbuild
Hi @Sergey Kolesnik ,
How can I inspect which version of Runtime is linked when compiled with /MT?
The answer in the link solves the problem:
/DEFAULTLIB:MSVCRTD (module compiled with /MDd)
or
/DEFAULTLIB:MSVCRT (module compiled with /MD)
or
/DEFAULTLIB:LIBCMT (module compiled with /MT)
And I recommend you to read this document, it will help you understand /MT and /MD.
Best regards,
Elya
If the answer is the right solution, please click "Accept Answer" and upvote it.If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
I was asking about the numeric version of the runtime. For instanse, linking with /MD will have a dependency on 14.0 version VCRUNTIME140D.dll, which can be seen from the dll name. But /DEFAULTLIB:libcpmtd itself does not reveal which version is used.
Hi @Sergey Kolesnik ,
To get the version of the DLL you need a command line tool. One solution is to use PowerShell.
The sample code is:
(Get-Item path-to-dll).VersionInfo.FileVersion
Hi @Sergey Kolesnik ,
May I know if you have got any chance to check my answer? I am glad to help if you have any other questions.