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'd like to reiterate the importance for providing unique names for libs and dlls. Our need is to support all combinations of 32/64/debug/release. It's a hassle to deal with same named libs and dlls all of which are incompatible. Same named dlls are a hassle to distribute to customers because they require unique paths. I can't just distribute them in a single directory. The customer needs to specify each directory in PATH for the dll to be found. My workaround is to 1) uniquely rename the dlls. 2) change my code to use LoadLibrary to dynamically load the appropriate dll. An alternative is to change the Windows/Linux projects to build with uniquely named libs/dll, or build with uniquely named static libs.
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'd like to reiterate the importance for providing unique names for libs and dlls. Our need is to support all combinations of 32/64/debug/release. It's a hassle to deal with same named libs and dlls all of which are incompatible. Same named dlls are a hassle to distribute to customers because they require unique paths. I can't just distribute them in a single directory. The customer needs to specify each directory in PATH for the dll to be found. My workaround is to 1) uniquely rename the dlls. 2) change my code to use LoadLibrary to dynamically load the appropriate dll. An alternative is to change the Windows/Linux projects to build with uniquely named libs/dll, or build with uniquely named static libs.
