What's the best way to distribute your SDK if the end user is required to link against the Debug CRT?

I work for a camera company and we provide an SDK for our customers. Historically we only provided a release build of our SDK that was built against the non-debug CRT. As part of our SDK package we provide a number of examples on how to use the SDK. The examples have Debug project configurations which use the debug CRT. In some cases we run into strange behaviour due to the fact that these examples and the library tha开发者_运维问答t they link against use different CRT's.

My questions is what is the appropriate way to deal with this sort of situation? Should we be distributing a debug version of our library that uses the debug CRT? As long as we don't provide a pdb or at most a stripped pdb, then all proprietary information should still remain hidden. Is it correct to assume that in doing this there should be no other negative effects other then a larger, not optimised binary?

Is it common practice to distribute a debug binary linked against the debug CRT or should we just continue distributing only the release build?

---

Yes, you'll need to distribute Debug and Release builds of your library. Built with respectively /MDd and /MD so the CRT can be shared. Different versions too, built against, say, the VS2005, VS2008 and VS2010 versions of the CRT.

This is of course painful. To narrow it down to a single library, you'll need to carefully craft your public interface so it doesn't expose any C++ objects or any pointers that need to be released by the client code. Exceptions are also taboo. A common solution is to use COM. Especially an Automation compatible interface is useable by most any language runtime in common use on Windows.

---

You might consider an Optimized Debug build, where it is set to use the debug versions of the libraries but has all the optimization flags set as they would be in a Release build. This will prevent subtle differences in execution from affecting the user experience.