Visual Studio setting to deal with missing MSVCP140D.dll

Question

My build computer is different than my target (although both are Windows 10).

I am using VS2017 with the latest updates.

The target machine has MFC: 14.12.25810

How do I set my project settings so that I can target that version of MFC. I keep getting an error of: missing MSVCP140D.dll

And when I try to install the VS2015 C++ redistributable, I get an error about conflicting versions. So I would rather stop targeting VS2015, and change to VS2017, or better include the redistributable in the folder I am installing.

Here are my VS2017 Project settings: (I am also using the latest Windows SDK).

---

UPDATE

I set Static Linked MFC, which added the switch /MTd to the command line:

/permissive- /Yu"stdafx.h" /GS /W3 /Zc:wchar_t /ZI /Gm- /Od /sdl /Fd"x64\Debug\vc141.pdb" /Zc:inline /fp:precise /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /MTd /FC /Fa"x64\Debug\" /EHsc /nologo /Fo"x64\Debug\" /Fp"x64\Debug\LinkWareMessageBus.pch" /diagnostics:classic 

However, now I get a bunch of errors on compile:

Severity Code Description Project File Line Suppression State Warning LNK4098 defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library LinkWareMessageBus D:\Source\LinkWareMessageBus\LINK 1
Severity Code Description Project File Line Suppression State Error LNK1120 6 unresolved externals LinkWareMessageBus D:\Source\LinkWareMessageBus\x64\Debug\LinkWareMessageBus.exe 1
Error LNK2019 unresolved external symbol __imp_calloc referenced in function nni_alloc LinkWareMessageBus D:\Source\LinkWareMessageBus\nng.lib(win_thread.c.obj) 1
Error LNK2019 unresolved external symbol __imp_rand_s referenced in function nni_plat_seed_prng LinkWareMessageBus D:\Source\LinkWareMessageBus\nng.lib(win_rand.c.obj) 1
Error LNK2019 unresolved external symbol __imp_strerror referenced in function nni_plat_strerror LinkWareMessageBus D:\Source\LinkWareMessageBus\nng.lib(win_debug.c.obj) 1
Error LNK2001 unresolved external symbol __imp_strncpy LinkWareMessageBus D:\Source\LinkWareMessageBus\nng.lib(http_server.c.obj) 1
Error LNK2019 unresolved external symbol __imp_strncpy referenced in function http_set_header LinkWareMessageBus D:\Source\LinkWareMessageBus\nng.lib(http_msg.c.obj) 1
Error LNK2019 unresolved external symbol __imp__beginthreadex referenced in function nni_plat_thr_init LinkWareMessageBus D:\Source\LinkWareMessageBus\nng.lib(win_thread.c.obj) 1
Error LNK2019 unresolved external symbol __imp__stricmp referenced in function nni_strcasecmp LinkWareMessageBus D:\Source\LinkWareMessageBus\nng.lib(strs.c.obj)

I also tried setting "Ignore All Default Libraries = No" but I still get the same error.

Here is the LINK command parameters:

/OUT:"D:\Source\LinkWareMessageBus\x64\Debug\LinkWareMessageBus.exe" /MANIFEST /NXCOMPAT /PDB:"D:\Source\LinkWareMessageBus\x64\Debug\LinkWareMessageBus.pdb" /DYNAMICBASE "flatbuffers.lib" "nng.lib" "mswsock.lib" "advapi32.lib" "ws2_32.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"nng.lib" /DEBUG /MACHINE:X64 /INCREMENTAL /PGD:"D:\Source\LinkWareMessageBus\x64\Debug\LinkWareMessageBus.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Debug\LinkWareMessageBus.exe.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"D:\Source\LinkWareMessageBus\nng\lib" /LIBPATH:"D:\Source\LinkWareMessageBus\flatbuffers\lib" /TLBID:1 

Answer 1

What I am doing now is just doing release builds with symbols.

https://msdn.microsoft.com/en-us/library/fsk896zz.aspx?f=255&MSPPError=-2147217396

This is especially useful now, since I am writing plugins for other software that does not like to load debug versions of the DLLs I create. Sometimes you can't see the local stack varibles for a function, but you can always see member and instance variables, as well parameters, so this works best for me, and then one does not have to worry about SDK binding issues like above.