What does the "Link Library Dependency" linker option actually do in Visual Studio 2010 - 2015 and upwards?

You have to give the setting the proper value to bring clarity:

enter image description here


2017 Re-Run. Yay.

TL;DR

This Option sets the default value(a) for the actual Link Library Dependecies on each project reference. If each project reference has LinkLibraryDependecies set, then it is in effect meaningless.

However, when adding a new reference, by default (in VS2010 and 2015) the new <ProjectReference> element in the vcxproj file does not have the setting set, so this option is relevant in that it provides the default for all newly added references, as long as their value isn't modified.

(a): It really should be the same for all Configurations (Debug/Release) and Platforms (Win32/x64) or things get really complicated.

Gory details

Hans pointed out that it appears to not do anything in VS2010 as such. However, this doesn't mean that it actually ain't used by VS/MSBuild.

The crux is how this option is inserted into the vcxprj file and how the defaults work for the <ProjectReference> setting in the msbuild file.

The setting on the Linker dialog as shown above is inserted as:

Not actually implemented

<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
...
  <ItemDefinitionGroup>
    <ClCompile>
...
    </ClCompile>
    <Link>
...
    </Link>
    <ProjectReference>
      <LinkLibraryDependencies>This option is not used by VS 2010!</LinkLibraryDependencies>
    </ProjectReference>
...
  </ItemDefinitionGroup>
</Project>

And while it appears to be somehow grouped together with the Link Option, that's just there to confuse you.

What this actually does in a given vcxproj file (or when coming from a .propsfile), is to set the default value of the Link Library Dependencies Value for each project dependency on the Frameworks and References section in a VS2010 VC settings dialog --

Link Lib in the References 2010

-- or in the subtree of the VS2015 References --

Link Lib in the References 2015

And this is relevant, because when you add a new project reference, the default entry in your vcxproj file will look like this:

...
  <ItemGroup>
    <ProjectReference Include="..\W32DynLib1\W32DynLib1.vcxproj">
      <Project>{96be134d-acb5-....-....-....bb6fe4a7}</Project>
    </ProjectReference>
  </ItemGroup>

You'll notice that the <LinkLibraryDependecies>true|false</..> sub element is missing here: This means you "global" setting will actually be used to set the default value.

If your global setting is false (or No), the project reference won't link in anything. If it's true, it will link in.

What's more:

  • If this setting, LinkLibraryDependency, is completely missing from your settings, it will default to true (from the Microsoft.Cpp[.Common].propsfile in the MSBuild folder).
  • If you happen to have the value This is not used in your global setting, this will be interpreted as true.
  • If you have the value False is the new truth!, or maybe No way in this setting, it will also be interpreted as true by the build.
  • The VS2015 GUI will display a warning if it cannot interpret the string here: String value 'False is the new truth!' cannot be translated to any value from type Boolean.
  • The VS2010 GUI will display False for ALL values, except false, even though this is then interpreted as true when building the project.

What's even more:

It seems that when converting old Solutions with vcproj files, the converter will take the old dependencies that were specified in the sln and the value of the vcproj project's Linker option, and actually set the LinkLibraryDependency for each ProjectReference it inserts into the new vcxproj - thats one reason I thought that this is a dead option for so long - most of our projects have a conversion history dating back to VS2005.


Here the thing is you have to go to, project properties -> common properties -> framework and references and then add new reference to your projects. Then only it will work in VS 2010 not like in early versions of VS