*.pp contentFiles not copied to output directory in 3.0 SDK
See original GitHub issueI’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 .ps1
s 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:
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (2 by maintainers)
Top GitHub Comments
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.
Addressed in #3771