Visual Studio 2017中C++的「项目引用」功能具体作用是什么？

Great question—this is such a common source of frustration when switching between C# and C++ in Visual Studio. Let’s break down what project references actually do, why they seem "useless" by default, and how to make them work like you expect.

First, the Core Purpose (That Works Out of the Box) #

The most basic and reliable job of a C++ project reference is enforcing build order. If you add ProjectB as a reference to ProjectA, Visual Studio guarantees that ProjectB will compile and build its output (.lib/.dll) before ProjectA starts compiling. Without this, you might run into race conditions where ProjectA tries to link against a library that hasn’t been built yet—this alone is a huge win for avoiding random build errors.

Automatic Library Linking (No Manual .lib Paths) #

If ProjectB is a static library or a dynamic library (with an import .lib), adding a project reference will also automatically link ProjectB’s library to ProjectA—you don’t have to manually add the .lib path to ProjectA’s Linker > Input > Additional Dependencies.

This happens behind the scenes: VS injects the path to ProjectB’s output .lib into ProjectA’s build process, even if you can’t see it in the UI. The only prerequisites are:

• ProjectB’s Configuration Properties > General > Configuration Type is set to either Static Library (.lib) or Dynamic Library (.dll)
• For dynamic libraries, ProjectB is configured to generate an import .lib (this is enabled by default in Linker > Advanced > Import Library)

Property Propagation (The "Missing" Part—It’s Opt-In) #

Here’s where things differ from C#: by default, Visual Studio doesn’t automatically pass ProjectB’s include directories, library directories, or other build properties to ProjectA. This is why most people end up using relative paths and .props files—but this isn’t because project references can’t do it; it’s because you have to opt into the behavior.

To make property propagation work like C# or CMake’s target_link_libraries, do this:

1. Mark properties as "Public" in ProjectB (VS 2017+):
   • Open ProjectB’s properties, go to any setting you want to share (like C/C++ > General > Additional Include Directories).
   • Click the small icon next to the property value (looks like a tiny page) and select Public. This tells VS to pass this property to any project that references ProjectB.
2. Verify reference settings in ProjectA:
   • Right-click ProjectA’s reference to ProjectB, select Properties.
   • Ensure Link Library Dependencies is checked (default is yes) — this enables the automatic linking we talked about earlier.
   • If you’re using static libraries, Use Library Dependency Inputs can be checked to link directly to ProjectB’s .obj files instead of the .lib, which can speed up incremental builds.

Why Do People Still Use Manual .props Files? #

A lot of this habit comes from older versions of Visual Studio (pre-2017) that didn’t support the Public/Private property system. Back then, there was no built-in way to propagate properties via project references, so teams relied on .props files to share include paths, compiler flags, etc.

Even now, some teams prefer manual .props files because they give explicit control over dependencies—no hidden automatic propagation that could introduce unexpected paths or flags into the build.

Comparing to CMake’s target_link_libraries #

CMake’s model is opinionated and defaults to propagating all public properties when you link targets. Visual Studio’s MSBuild model is more flexible (some would say verbose) because C++ builds are often highly customized. The end result can be the same—automatic dependency propagation—but you have to configure it explicitly in VS, whereas CMake does it out of the box.

内容的提问来源于stack exchange，提问作者solvingJ