1

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).

enter image description here

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
Jason Aller
  • 3,541
  • 28
  • 38
  • 38
Dr.YSG
  • 7,171
  • 22
  • 81
  • 139
  • 1
    Possible duplicate of [MSVCP140.dll missing](https://stackoverflow.com/questions/32998902/msvcp140-dll-missing) – Andrew Truckle Jul 04 '18 at 21:37
  • I saw that. But I am looking for a new solution, since installing the redistribution is not working easily for me. – Dr.YSG Jul 04 '18 at 21:42
  • 1
    Have you tried to build statically? – Andrew Truckle Jul 04 '18 at 21:46
  • Vs2017 has a project property for the Use of MFC. (See above)I tried standard & static. I cannot try the /mtd switch till tomorrow – Dr.YSG Jul 04 '18 at 21:48
  • 1
    Put `"Use of MFC: Use MFC in a Shared DLL"` or `"Use MFC in a Static Library"` The advantage of shared library is that it can receive security updates. If you are installing the shared library in your own directory, you don't gain any benefit, so just use the static version if you want things easier. Also, I get thrown off sometimes when I am in "Release" mode, but it shows me "Debug" configuration, or vice versa. Watch out for that. – Barmak Shemirani Jul 05 '18 at 05:19
  • thank you @BarmakShemirani and Andrew. I am only building Debug releases till this gets working. I tried the "Use MFC in a Static Library", and the result is in the update above. (The DLL approach builds, but I have no idea where to find the shared DLL, it is not in the x64/Debug folder. – Dr.YSG Jul 05 '18 at 15:57
  • In Configuration -> Linker -> Input set `"Ignore All Default Libraries = No"` Show the command line for Linker as well – Barmak Shemirani Jul 05 '18 at 17:06
  • @BarmakShemirani Just tried what you suggested. Added the link command to the UPDATE of the problem. No change in results. Boy, I think it is time I learned CMAKE but there are not many resources for windows usage. – Dr.YSG Jul 05 '18 at 17:14
  • Looks like you have external libraries (`"nng.dll"` ...) These libraries have to be created by the same version of Visual Studio. Version matters, Debug/Release matters. I might have sent you in the wrong direction, you might need shared dll, targetting VS2015. You are targeting x64. Was it 64-bit earlier? Are you using any MFC classes? Console programs are usually not MFC, and `"Standard Windows Libraries"` is enough. Maybe it's `Ignore All Default Libraries = Yes`. – Barmak Shemirani Jul 05 '18 at 18:48
  • nng (nanomsg) and google flatbuffers are two static libs I am using (built in VS2017 with CMAKE). I just rebuilt them since VS2017 updated itself this week. This is dirt simple console program. Just opens a socket and encodes the messages with flatbuffers. Works fine on my desktop. I just want it to work on my Win10 VM (located on an OpenStack cloud). – Dr.YSG Jul 05 '18 at 20:22
  • Why when I build it with VS2017, does it need a shared dll vor VS2015? Also, the project is currently targeted for the Windows SDK version 10.0.171340.0 Is that something I should change? – Dr.YSG Jul 05 '18 at 20:44
  • It doesn't look like you need MFC. Choose "Windows Standard Libraries". I thought you have MFC/C++ classes which have to be rebuilt with the exact same version, but you are probably using simple C interface for external libraries, so that's fine. I suggest creating a new console project: File->New->Project->Visual C++->Windows Console Application. Add the C++ files and third party libraries. – Barmak Shemirani Jul 05 '18 at 21:28
  • 2
    You are deploying a debug build of your application (note the trailing `D` for MSVCP140D.dll). The debug version of the MFC binaries are part of Visual Studio and not redistributable. You need to deploy a release configuration instead. – IInspectable Jul 05 '18 at 23:14
  • @IInspectable that fixed it.Can you write this up as an answer, so I can give you credit (but I also want to give a thanks to Barmak since his suggestions also contributed and I appreciate his patience) – Dr.YSG Jul 06 '18 at 14:17
  • This question has been asked and answered hundreds of times before. You are free to accept the duplicate. – IInspectable Jul 07 '18 at 12:05
  • 1
    Possible duplicate of [Fixing the "MSVCP110D.dll is missing from your computer" issue](https://stackoverflow.com/questions/21458908/fixing-the-msvcp110d-dll-is-missing-from-your-computer-issue) – IInspectable Jul 07 '18 at 12:05

1 Answers1

2

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.

Dr.YSG
  • 7,171
  • 22
  • 81
  • 139