3rd party XML documentation files in NuGet packages are not copied to my project's build folder

I’ve dug around for a solution to this problem, but I only find issues related to dotnet publish not including a project’s xml documentation. My issue is that XML documentation files in NuGet packages are not copied to my project’s build folder. I hope the distinction is clear to a human (google couldn’t get it).

Steps to reproduce

Add some_other_library nuget package which includes xml documentation to you project. Do dotnet build

Expected behavior

The some_other_library.xml is included in the build (output) folder like so: (screenshot from output of VS 2017)

Actual behavior

some_other_library.xml file is not present in the build (output) folder: (screenshot of output of dotnet cli)

Environment data

dotnet --info output:

.NET Command Line Tools (2.1.101)

Product Information:
 Version:            2.1.101
 Commit SHA-1 hash:  6c22303bf0

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.101\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.6
  Build    : 74b1c703813c8910df5b96f304b0f2b78cdf194d

[Barsonax]

@JoFrMueller you can do this to copy the xml and/or pdb files to the build output if it exists:

  <Target Name="CopyReferenceFiles" BeforeTargets="Build">
    <ItemGroup>
      <ReferenceFiles Include="%(Reference.RelativeDir)%(Reference.Filename).xml;%(Reference.RelativeDir)%(Reference.Filename).pdb" />
    </ItemGroup>
    
    <Message Text="Copying reference files to $(OutputPath)" Importance="High" />
    <Copy SourceFiles="@(ReferenceFiles)" DestinationFolder="$(OutputPath)" Condition="Exists('%(RootDir)%(Directory)%(Filename)%(Extension)')" />
  </Target>

Also see my blog about this https://the-photographing-programmer.com/packagereferences-and-xml-documentation/

Granted it would be nice if there was build in support for this common use case but this seems to work pretty well and takes into account transitive dependencies as well and doesn’t lock your project into a specific targetframework.

We use this in our new project template for our game engine https://github.com/Barsonax/DualityProjectTemplate/blob/master/Source/Duality/Directory.Build.props#L12

[MonDeveloper]

This limitation is really painfull when the xml documentation are the one describing the model packed with NuGET and used on the WebAPI contracts where something like swagger is used to self document the WebApi themselves, in such a case there’s no possibility to auto-describe the contracts (since it is autodiscovered using the xml documentations)