   Visual Studio 2005 Project Settings
  I am having all sorts of project configuration problemsI am trying to have a solution, that has two projects. One is my game (Game) and one is my DLL (GameDLL). I made a custom build Configuration named "Game + DLL (Debug)" and copied over the Debug settings. I then right clicked on the Game projects, went to project dependencies and selected my other project, "GameDLL". However, when I do this I get a ridiculous amount of linker errors. If I build these projects seperatly without project dependencies and on the default Debug configuation I get no linker errors. 1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library1>MapManager.obj : error LNK2001: unresolved external symbol __CrtDbgReportW1>libcpmtd.lib(stdthrow.obj) : error LNK2001: unresolved external symbol __CrtDbgReportW1>EngineBase.obj : error LNK2019: unresolved external symbol __CrtDbgReportW referenced in function "public: class Engine::States::CEngineStateBase * & __thiscall std::vector<class Engine::States::CEngineStateBase *,class std::allocator<class Engine::States::CEngineStateBase *> >::operator[](unsigned int)" (??A?$vector@PAVCEngineStateBase@States@Engine@@V?$allocator@PAVCEngineStateBase@States@Engine@@@std@@@std@@QAEAAPAVCEngineStateBase@States@Engine@@I@Z)1>ShaderManager.obj : error LNK2001: unresolved external symbol __CrtDbgReportW1>SpriteManager.obj : error LNK2001: unresolved external symbol __CrtDbgReportW1>TextureManager.obj : error LNK2001: unresolved external symbol __CrtDbgReportW1>libcpmtd.lib(xdebug.obj) : error LNK2019: unresolved external symbol __malloc_dbg referenced in function "void * __cdecl operator new(unsigned int,struct std::_DebugHeapTag_t const &,char *,int)" (??2@YAPAXIABU_DebugHeapTag_t@std@@PADH@Z)1>libcpmtd.lib(xdebug.obj) : error LNK2019: unresolved external symbol __free_dbg referenced in function "void __cdecl operator delete(void *,struct std::_DebugHeapTag_t const &,char *,int)" (??3@YAXPAXABU_DebugHeapTag_t@std@@PADH@Z)1>C:\Users\Joseph\Desktop\Athena\debug\GameDLL.dll : fatal error LNK1120: 3 unresolved externals1>Build log was saved at "file://c:\Users\Hack\Desktop\NEWPROJECT\GameDLL\Game + DLL (Debug)\BuildLog.htm"1>GameDLL - 9 error(s), 1 warning(s)Anyone know why?   
  Are you statically linking to the Visual C++ Runtime (I'm guessing you're using Visual Studio)?  If you are, try dynamically linking to it.  Also make sure that they are both using either Unicode or Multibyte characters.[edit]Actually, on second thought, I'm not sure if what I said has any real effect for two separate projects where one is an executable and one is a DLL.  Might as well give it a try though.   ;  Ah, well I got that fixed but I keep getting these errors in my DLL project. Any idea why?Warning2warning C4251: 'Engine::CObjectBase::m_mTransform' : struct 'D3DXMATRIX' needs to have dll-interface to be used by clients of class 'Engine::CObjectBase'Warning3warning C4251: 'Engine::CObjectBase::m_vGeneralComponents' : class 'std::vector<_Ty>' needs to have dll-interface to be used by clients of class 'Engine::CObjectBase'   ;  1) warning != error2) MSVC has  pages clarifying error messages for a reason.   ;  On the original issue:You're mixing the debug and release C runtime libraries there. LIBCMT stands for "libc multithreaded" and is the statically linked release runtime for C. LIBCPMTD stands for "libc++ multithreaded debug", so it's the statically linked debug runtime for C++.However, you wouldn't see this error if the inconsistency was between your 'GameDLL' and 'Game'. The error messages you're getting suggest that you have linked something else (a non-dll 3rd party library like libpng, d3dx or SDL for example) and that you're using the wrong runtime.The runtime setting can be changed under project settings, C/C++, code generation, use runtime library.If you use the static runtime (like you are now), you can not allocate memory in your GameDLL and free it in your Game or vice versa because both will have their own heap and their own copy of the memory management code.;  On the warnings:You're seem to be exporting entire classes in your GameDLL that contain fields which are not DLL-exported. For example, if you had a class __declspec(dllexport) Character { D3DXVector3 Position; }; that would cause this warning because there are no DLL exports for the D3DXVector3 class/struct methods.To get rid of them, either hide such internals from your exported classes (see pImpl idiom and implementation hiding in general) or selectively export, eg.#define DLLFUNC __declspec(dllexport)class ExportedClass {  public: DLLFUNC PublicMethod();  private: void privateMethod();  private: D3DXVector3 privateField;};Quote:Original post by CygonOn the warnings:You're seem to be exporting entire classes in your GameDLL that contain fields which are not DLL-exported. For example, if you had a class __declspec(dllexport) Character { D3DXVector3 Position; }; that would cause this warning because there are no DLL exports for the D3DXVector3 class/struct methods.To get rid of them, either hide such internals from your exported classes (see pImpl idiom and implementation hiding in general) or selectively export, eg.#define DLLFUNC __declspec(dllexport)class ExportedClass {  public: DLLFUNC PublicMethod();  private: void privateMethod();  private: D3DXVector3 privateField;}I do indeed want to export the entire class, the functions and the variables though. How would this be possible?   ;  If the non-exported types are in your GameDLL, just export them.If you want to publish non-exported data types from another library (like from D3DX in the previous example), you could try one of these things:- ignore those warnings (you can disable a specific warning in the project settings) and be aware of the consequences. Which are that you project is now bound to a very specific version of the library (in the example, D3DX) and if you ever recompile you GameDLL project using another version of the library than used in the Game project, things probably won't work out.- wrap the types in your own classes. Comes with a performance hit, since you will internally need to copy your own type over to the library's original type, or manage one of the library's types as a private field in your wrappers.- return them by reference or by pointer. Calling methods on these types using the original library functions still carries the same risk, but I think the compiler won't be as picky in this case.   