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: We are deeper into beta testing and this issue of non-unique filenames is darn annoying. For deployment, instead of simply copying .DLL files from the C++ Rest SDK binary distribution to a common directory, my workaround is to give uniqueness by using 32-bit debug dlls ('d' suffix) and 64-bit release dlls (non 'd' suffix). Otherwise the .DLL names would be identical resulting in a name collision or worse, deploying the wrong DLL. It would be really helpful if you could change the lib/dll naming scheme something like what I proposed 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: We are deeper into beta testing and this issue of non-unique filenames is darn annoying. For deployment, instead of simply copying .DLL files from the C++ Rest SDK binary distribution to a common directory, my workaround is to give uniqueness by using 32-bit debug dlls ('d' suffix) and 64-bit release dlls (non 'd' suffix). Otherwise the .DLL names would be identical resulting in a name collision or worse, deploying the wrong DLL. It would be really helpful if you could change the lib/dll naming scheme something like what I proposed above.