2

I have a project that I'm trying to get updated to the universal CRT, and I'm still seeing a dependency on vcruntime140.dll and msvcp140.dll, which I think should have been replaced with a ucrtbase.dll, as well as api-ms-win-crt* dlls.

I've already checked out this response here, and this blog post, which explain things pretty well, but still no luck. Here's what I've changed:

  • Platform Toolset: Visual Studio 2019 (v142)
  • Windows SDK version: 10.0 (latest installed version)
  • Additional include directories: added $(UniversalCRT_IncludePath)
  • Additional library directories: added $(UniversalCRT_LibraryPath_x86)

I also updated my linker dependencies to this set:

  • ucrt.lib
  • vcruntime.lib
  • msvcrt.lib
  • user32.lib
  • advapi32.lib
  • Wsock32.lib
  • Crypt32.lib
  • ws2_32.lib

But when I run dumpbin /dependents mydll.dll

File Type: DLL

Image has the following dependencies:

api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
VCRUNTIME140.dll
USER32.dll
ADVAPI32.dll
WSOCK32.dll
CRYPT32.dll
WS2_32.dll
MSVCP140.dll
bcrypt.dll
KERNEL32.dll

Summary

    E000 .data
   66000 .rdata
    E000 .reloc
    1000 .rsrc
  14A000 .text

Is there something else I'm missing to be able to drop the dependency on the specific CRT version?

Chris Bardon
  • 430
  • 4
  • 13
  • Lots of language runtimes take a dependency on the CRT to get basic stuff done. But if you program in C++ then you really do need vcruntime and msvcp. – Hans Passant Apr 22 '20 at 21:21
  • 1
    I'm not as concerned about the dependency on those files, but I thought the point of the universal CRT was that there was a single DLL version (ucrtbase.dll) updated in place, rather than a specific version (VCRUNTIME140.dll). I just tested a clean win10 1903 machine, and it has ucrtbase.dll, just not the VCRUNTIME140.dll. I can deploy it, but I'm trying to minimize dependencies, and use the OS updated libraries. – Chris Bardon Apr 22 '20 at 21:43
  • 1
    https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=1273 – Hans Passant Apr 22 '20 at 22:02
  • 1
    Right...except that's from 2014, and the [blog post from 2015](https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/) clearly states:"The Universal CRT is a Windows operating system component. It is a part of Windows 10." I suppose that means that all old ideas are new again? – Chris Bardon Apr 23 '20 at 00:05
  • This morning, I tried something new. File->new project->DLL, and created a brand new vcxproj file with no custom code in it. According to the original post on UCRT, this should mean that all my dependencies are on the universal library, and not the version-specific one. Even here (and after explicitly linking ucrt.lib;vcruntime.lib;msvcrt.lib; and adding the UCRT include and lib directories), the DLL still depends on VCRUNTIME140.dll. – Chris Bardon Apr 23 '20 at 12:39

1 Answers1

4

I've done some more digging, and found this page that says the following:

Starting in Visual Studio 2015, the CRT has been refactored into new binaries. The Universal CRT (UCRT) contains the functions and globals exported by the standard C99 CRT library. The UCRT is now a Windows component, and ships as part of Windows 10.

Great, that's what I expected. Just below though is this:

The vcruntime library contains Visual C++ CRT implementation-specific code, such as exception handling and debugging support, runtime checks and type information, implementation details and certain extended library functions. This library is specific to the version of the compiler used.

Which implies that there is still a non-universal VC++ dependency that gets linked in by VS. To me, this implies that a dependency-free DLL doesn't really exist (at least not something built with VC++), since you'll always have a vcruntime dependency.

There is always the option of static linking (/MT), but in my case, I'm also looking at a DLL that has /clr, and the two options are mutually exclusive. Application local deployment (just copy vcruntime140.dll with the binaries) also seems to work, and may be the best option for something that I want to be a portable/xcopy deployment.

I'm going to mark this as an answer for now, but if there's a way around this, I'd be interested in seeing it.

Chris Bardon
  • 430
  • 4
  • 13