Visual Studio: how to handle project dependencies

问题:

I'm writing a program (in C++), which requires several VS projects, that I would like to put in the same VS solution. I'm using Visual Studio 2010.

Here is simply the wanted architecture : I'm using a 3rd party library (A) for my project, I have all the headers and .lib files, that I compiled with the source code.

With this library, I'm writing my own classes and function. That is my project (B).

Then I would like to develop two interfaces for the users: A command line interface (C1) and a GUI interface (C2), that are using the classes and functions defined in (B).

A <-- B <-- C1
        <-- C2

I'm new to Visual Studio, and I don't know how to handle these dependencies properly. Shall I use project dependencies (in the solution properties) or references (in the project properties) ? In fact, I'm not sure what dependencies and references are doing exactly.

Shall I compile B into some .lib library, or do something else ? If I do so, have to link only B.lib to my C1 and C2 projects, or should I also link A.lib (in other words, is the content of A.lib included somehow in B.lib ?). And of course I would want the dependencies to be handle well, in order to always work with the up-to-date version of each project.

Is there a good way of doing it ? Thank's in advance, and have a nice week-end :)

回答1:

The policy at the company I work for is to use project references.

The project references are more useful since they keep the information of what projects a given project depends on with the project. If you then have to add the project to a new solution you do not have to go back to the old solution file to find out what projects a given project depends on.

回答2:

Yes. Use Project References.

Here is the official answer from Microsoft. While the page talks about .NET, its almost the same for native projects too.

TL;DR version:

Advantages of Project References:

1. They work on all development workstations where the solution and project set are loaded. This is because a project Globally Unique Identifier (GUID) is placed in the project file, which uniquely identifies the referenced project in the context of the current solution.
2. They enable the Visual Studio .NET build system to track project dependencies and determine the correct project build orders.
3. They avoid the potential for referenced assemblies to be missing on a particular computer.
4. They automatically track project configuration changes. For example, when you build using a debug configuration, any project references refer to debug assemblies generated by the referenced projects, while they refer to release assemblies in a release configuration. This means that you can automatically switch from debug to release builds across projects without having to reset references.
5. They enable Visual Studio .NET to detect and prevent circular dependencies.

Here is another nice article on Project Settings Changes in VS 2010 that also states that references are to be preferred over Project Dependencies. In fact, the article also says that the VS2010 solution converter automatically detects Project dependencies and changes them to Project references.