Is there any good reason to not include STL types in DLL headers?

[RaduV]

I want some class methods in my dll to return strings and std::string seems the easiest way to do it. However I don't know what issues this might cause with the C++ runtime library. Should I not do this? Should I link statically with the C++ library. And (i'm a bit embarressed to ask) how do I link statically with the C++ library in visual studio?

[Computergeek01]

The first question you should be asking is: "Should this really be a DLL?". Shared libraries are great if you expect multiple applications to be using that source code at the same time. For most custom classes, that simply isn't the case.

[modoran]

You link statically using /MT or /MTd switch. It is strongly not recommended to link statically against the C++ runtime when messing with different DLLs.

[RaduV]

computergeek01:
I made it a dll because it contains wrappers for some win32 controls. If I update the dll then I wouldn't have to rebuild existing applications that use it, right? That was my reasoning for choosing a dll.

modoran:
Thanks. Can you elaborate why it's a bad idea?

[LB]

Many structures change size and gain or lose members depending on whether you are compiling in debug or release, as well as hundreds of other various compiler settings. You have to make sure that your project using the DLL has all the same settings as the project that was used to create the DLL. It's a mess, and if you get it wrong, it can lead to subtle bugs or annoying crashes as the DLL expects your structures to be one way and your structures are actually a different way, and vice versa.