To prevent mismatching .lib and .dll files in Debug/Release and 32/64, there should be both a visual difference and an erroring during linking. Currently there is a naming difference between Debug/Release but no naming difference for 32/64. However, there is no linker error if you mismatch Debug/Release libs with Debug/Release dlls. I've spent hours trying to find a logic error when it was simply a mismatch dll vs lib problem. The linker didn't complain and was happy to resolve the mismatched files. If this is not done, there will be more people falling prey.
Additionally, a naming difference will allow all .lib and all .dll files to be distributed in a common application directory. That makes app distribution of .lib/.dll a bit easier with no chance of error. I believe this should be considered best practice.
Comments: I fell into the error because the filename was generic, not immediately obviously wrong. Say you see a file named my.lib. What do you know about linking to it? Not much. Could be any combination of Debug/Release x86/x64/Arm32/Arm64 (maybe even Win/Linux/RT). That's what I see in cpprest120_1_4.lib. It is not immediately obvious where the filename is to be used, or is NOT to be used. Thus I propose a naming scheme like the following which are immediately obvious: cpprest120_1_4_Release_x86.lib cpprest120_1_4_Release_x64.lib cpprest120_1_4_Debug_x86.lib cpprest120_1_4_Debug_x64.lib but definitely not continuing with a generic name like cpprest120_1_4.lib The bigger picture is that Visual Studio should make this the project creation default by use of VS macros. You can't commingle a lib between release and debug so the default project creation should unique the lib/dll names by use of VS macros. With the proliferation of platforms (newly added Arm and RT) it might look like: cpprest_1_4_$(PlatformToolset)_$(Configuration)_$(PlatformTarget).lib (e.g. cpprest_1_4_v120_Debug_x86) or better yet, let's have Visual Studio offer a single macro that expands to the above cpprest_1_4_$(PlatformFQ) which is easily remembered and expands to the above.
Additionally, a naming difference will allow all .lib and all .dll files to be distributed in a common application directory. That makes app distribution of .lib/.dll a bit easier with no chance of error. I believe this should be considered best practice.
Comments: I fell into the error because the filename was generic, not immediately obviously wrong. Say you see a file named my.lib. What do you know about linking to it? Not much. Could be any combination of Debug/Release x86/x64/Arm32/Arm64 (maybe even Win/Linux/RT). That's what I see in cpprest120_1_4.lib. It is not immediately obvious where the filename is to be used, or is NOT to be used. Thus I propose a naming scheme like the following which are immediately obvious: cpprest120_1_4_Release_x86.lib cpprest120_1_4_Release_x64.lib cpprest120_1_4_Debug_x86.lib cpprest120_1_4_Debug_x64.lib but definitely not continuing with a generic name like cpprest120_1_4.lib The bigger picture is that Visual Studio should make this the project creation default by use of VS macros. You can't commingle a lib between release and debug so the default project creation should unique the lib/dll names by use of VS macros. With the proliferation of platforms (newly added Arm and RT) it might look like: cpprest_1_4_$(PlatformToolset)_$(Configuration)_$(PlatformTarget).lib (e.g. cpprest_1_4_v120_Debug_x86) or better yet, let's have Visual Studio offer a single macro that expands to the above cpprest_1_4_$(PlatformFQ) which is easily remembered and expands to the above.