问题
When you link to the MS Visual C Runtime Library from your (C++) program, you normally only link against one version, the release or debug version: Either MSVCR<ver>.dll or MSVCR<ver>D.dllor with VS2015 the ucrtbase[D].dlls and their additional dependencies.
Disclaimer: Mixing their usage and exchanging pointers (etc.) from one to the other will lead to crashes and insanity -- this is not what this question is about.
However, when your C or C++ program links to a 3rd party (C) DLL that is only delivered in a release variant, and that DLL uses MSVCR internally(!), it will link to and load the release version, even when you run your program in the debug version. (A variant of this is that the 3rd party lib could, again internally, also use a completely different MSVCR###.dll version than you, in which case they'd differ even in your release build.
This is a pretty standard scenario for me, and I always assumed that this "just works" (which indeed it seems it does).
I've been wondering however, whether this is actually an expected and supported scenario for these MS libraries? Is it? Any experiences to the contrary?
回答1:
Yes, this is supported, and is common.
For example, if you build a C++/CLI Windows Forms app, you'll probably end up loading at least three different CRTs into the process: your program will use msvcr.dll, the CLR will use msvcr120_clr0400.dll, and various operating system components loaded in your process may use msvcrt.dll.
来源：https://stackoverflow.com/questions/36693436/is-loading-both-release-and-debug-version-of-msvcr-or-ucrt-etc-officially-sup