10

I have been using Visual Studio for quite some time now, developing mainly for C++. I was often in need to create solutions, that contained multiple modules (projects) - for example utility library, that was consisted of couple .dll files.

When there is a need for one module (A) to use another (B), there is standard pattern for this:

  1. Include required header.
  2. Link output library file from B (for example, in VS: Project Config -> Linker -> Input -> Additional Dependencies -> 'B.lib').
  3. [Optional] Setup proper build order (so B is built before A).

Recently I started to play around with C#, because I decided to develop some GUI-based tools for my engine with it (it's much easier, than using C++ and external libraries like Qt or wxWidgets). I learned, that in C#, such dependencies are set using 'References':

enter image description here

I was very surprised, when I discovered, that this option is also applicable for C++ projects!

Indeed, after I created sample solution and set dependencies this way, everything was working fine, without any additional configuration like "Linker input" or something.

My question is: what does exactly this option do for C++ projects? I am interested in all profits and potential trade-offs.

I know already, that it causes linking output from other projects set as dependencies. Anything else? Perhaps some runtime dependencies between referenced modules? How does it affect generated output?

Mateusz Grzejek
  • 11,698
  • 3
  • 32
  • 49
  • A project reference automatically takes the output from the corresponding build configuration of the other project (Debug library for Debug build of application, etc). It would be a fair bit of work to set that up manually. – Ben Voigt Apr 11 '15 at 13:38
  • Also, since you mentioned DLLs, yes the project reference will pull in both build outputs, the .lib import library and the .DLL for runtime. – Ben Voigt Apr 11 '15 at 13:39

1 Answers1

15

It was originally meant to only be used in C++/CLI projects. And did the exact same thing that adding references to a C# project did, you pick .NET reference assemblies that you need to get the project to compile.

But this confused a great many C++ programmers, they thought it should contain something generally useful. Probably because it is under the "Common Properties" heading. Lots of questions about it.

Fast forward to VS2010, a version that was unfinished. One of the few cases where a Microsoft project overshot its intended shipping date. They got an extra 6 weeks to work down the bug-list. But that wasn't enough, the feature that was supposed to make it easier to link dependencies was not actually implemented or disabled.

So at VS2012 they decided to do it a different way and make Add Reference useful to a native C/C++ project as well. You always pick a project reference, it needs to be a static library or a DLL project. One that produces a .lib file. And it automagically tells the linker to link that .lib file. Nothing else, it simply adds the .lib file to the linker command line. Works well.

Update: changed again for VS2015, it now has a References node. Right-click it to add references to another project.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 1
    Seems much more clear than messing up with manual editing of `Linker input` or `#pragma comment`. – Mateusz Grzejek Apr 22 '15 at 18:19
  • "... it needs to be a static library or a DLL project. One that produces a .lib file." -- but only a static library generates .lib file, while a DLL project doesn't generate a .lib file, right? – athos Oct 16 '16 at 07:27
  • 1
    It does, the import library. It needs to be linked by any project that uses the DLL so that the linker knows that an identifier exists in another executable file. – Hans Passant Oct 16 '16 at 07:39
  • 1
    @athos there are generally two ways to do linking, either implicitly or explicitly. you might be thinking of explicit linking where a lib file is not required and the calling application dynamically links to a lib file by loading the symbols associated. I believe Microsoft does not recommend explicit linking since it is the root cause of many runtime failures. implicit linking is advised instead which generates a lib file telling the calling application where the symbols are relating to the .h include file – CJC Mar 22 '17 at 06:06