Proper way to build DLL's with multiple projects?

Okay so i am trying to convert some projects into DLL's. These are all visual studio 2008 projects, and are all written in C++.

We have 9 different projects(all under 1 solution in Visual Studio 2008). E.g.:

RasterTools\
 RasterDataset.h
 RasterDataset.cpp
 Point.h
 Point.cpp
 <... insert like 50 more cpp files ...>

CoreTools\
 Image.h
 Image.cpp
 CoreUtilities.h
 CoreUtilities.cpp
 <... insert more ...>

<... insert 7 or more projects ...>

Now the thing is certain projects use other project's classes. For example Image.h uses Point.h, and CoreUtilities.h has some functions for dealing with Points. What is the proper way to build a DLL when you have multiple projects that are all intertwined.

Basically we want to have the following:

CoreTools.dll
RasterTools.dll
<other projects.dll>

I understand how to handle the __declspec(dllexport) and dllimport fine, through macros. But when i attempt to build for example the CoreTools.dll i get linker errors where ever i use a class or functionality not contained within that project. For example when building coreTools.dll i get linker errors for any of the Point Class functions.

How can i deal with this?

EDIT

I tried this, and basically i noticed that almost all of the checkboxes were grayed out sinc开发者_如何学Ce its results in circular dependencies. :(

If you right-click on the project which throw ups the linker errors and choose 'Project Dependencies...' you'll see a list of all other projects in your solution.

Check the boxes next to the (DLL) projects you need to link with and Visual Studio will automatically link to it (and ensure the dependencies are built before the clients).

For each DLL you build you should also build a LIB. If Project B (B.DLL) references entries in Project A (A.DLL), then Project A is built first, it creates A.DLL and A.LIB, then Project B can add A.LIB to optional link libraries to resolve its references. Then C.DLL that depends on B.DLL can include in the link step B.LIB and so on and so forth.

At least this is what happens at the very low, build/make level. The dev environemnt may do all these under the covers for you if you choose the project dependencies right, as leegent suggests.

If you have circular dependencies between your DLLs, you'll have to resolve them by moving stuff around so that you get layered DLLs, with each DLL at a given level only using code from levels below.