*.pp contentFiles not copied to output directory in 3.0 SDK

I’ve been digging into this issue whereby a .pp file inside a package contentFiles (with copyToOutput="true") via PackageReference is not copied into the output directory during a dotnet publish / dotnet build. This works fine with .NET Core SDK 2.2.* but is broken in 3.0.100. Non-.pp files work fine.

I have debugged the MSBuild process and can see that the files are transformed successfully but they do not get copied to the output unlike non-.pp files.

My test project/package structure is basic and looks like this:

[Library A (TestAbc)] <== (PackageReference) == [Exe B]

Library A’s .nuspec:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>TestAbc</id>
    <version>160.0.0</version>
    <authors>TestAbc</authors>
    <owners>TestAbc</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Package Description</description>
    <dependencies>
      <group targetFramework=".NETFramework4.7.1" />
    </dependencies>
    <contentFiles>
      <files include="any/any/Test.ps1.pp" buildAction="Content" copyToOutput="true" />
      <files include="any/any/NonTransformed.ps1" buildAction="Content" copyToOutput="true" />
    </contentFiles>
  </metadata>
</package>

Exe B’s csproj (I’ve also tried targeting netcoreapp3.0)

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net472</TargetFrameworks>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="TestAbc" Version="163.0.0" />
  </ItemGroup>
</Project>

My dotnet version:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional>dotnet --version
3.0.100
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional>dotnet --list-sdks
3.0.100 [C:\Program Files\dotnet\sdk]

My build command - I couldn’t figure out how to get binlogs from msbuild via the dotnet publish command so I used the CopyLocalLockFileAssemblies property workaround although I’m not sure this is required with 3.0 SDK (see here):

C:/Program Files/dotnet/dotnet.exe --diagnostics msbuild /target:Build /property:PackageOutputPath=C:/Projects/test/bin/packages /property:IncludeSymbols=true /property:IncludeSource=true /property:CopyLocalLockFileAssemblies=true /property:Version=1.0.0 /property:configuration=Release "C:/Projects/squid2/src/ExeA/ExeA.csproj" -restore /bl:build.binlog -v:diag

After this command I see NonTransformed.ps1 in the output folder but not Test.ps1 (or Test.ps1.pp). I would expect to see both .ps1s in my output folder at that point.

Here’s my debugging so far:

I see the .pp file getting picked up:

It gets copied to a temp directory without the .pp extension (obj\Release\net472\NuGet\9374D6CD1CF741AA241FA0906DC657D57C8CB116\TestAbc\165.0.0\Test.ps1 in this case).

Then I see the preprocessor task running and see that the file has now been overwritten/updated with the template tokens replaced.

I notice later in the process that the 2 files are listed side by side but the TargetPath looks wrong (to my untrained eye) under the Test.ps1 element - first difference is the content path is an absolute path for the NonTransformed.ps1 but a relative path for Test.ps1. The task AssignTargetPath is used to generate a TargetPath (see here) which generates the correct one on NonTransformed.ps1 but not Test.ps1. UPDATE From tracing the 2.2 build, I can see it is the same in 2.2 so this is fine.

I can’t figure out where Test.ps1 is being dropped but later on I clearly see NonTransformed.ps1 alone in the copy task:

My output dir afterwards:

Exact same build but with SDK 2.2.402:

I’ve included my 2.2 and 3.0 binlogs here for comparison:

msbuild-binlogs.zip

[lscpike]

Digging through the code a little it seems the _ContentCopyLocalItems is no longer used. That seems to be where the .pp file output was previously added to the ReferenceCopyLocalPaths.

See https://github.com/dotnet/sdk/commit/1936ebd7307cebd6c5d1d8d699b9844f73b8fb2c#diff-726c4af93875efa855c29e94f7c0b33eL498

Feels like an accidental bug to me.

[sfoslund]

Addressed in #3771