Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content project item in .xproj when using CopyToOutputDirectory=Always does not work in PackageReference-based dependencies #11108

Closed
guillermooo opened this issue Dec 7, 2024 · 1 comment

Comments

@guillermooo
Copy link

guillermooo commented Dec 7, 2024

Issue Description

The Content MSBuild item type together with the CopyToOutputDirectory option set to Always works differently in Project to Project references (expected result) vs PackageReferences (unexpected result).

Steps to Reproduce

Pre-requisites

gcm -ErrorAction Stop nuget.exe

Set up workspace

mkdir CopyToOutputBug | cd

mkdir .nugetfeed > $null
dotnet nuget add source .nugetfeed -n TestFeed

dotnet new classlib -o A
dotnet new classlib -o B

dotnet new sln
dotnet sln add .\A\
dotnet sln add .\B\

'CHANGELOG PROJECT A' > .\A\CHANGELOG.txt

.\A\A.csproj # Starts with Visual Studio

In visual Studio, set .\A\CHANGELOG.txt to Build Action Content, Copy to Output Directory Always. Save VS project.

Image

cat .\A\A.csproj

Expected output:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <None Remove="CHANGELOG.txt" />
  </ItemGroup>

  <ItemGroup>
    <Content Include="CHANGELOG.txt">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

</Project>

Scenario #1 - Project to Project reference does the expected

dotnet add .\B\ reference .\A\

dotnet build

cat .\B\obj\project.assets.json | sls -Context 10 CHANGELOG # No output, assumed good.
ls .\B\bin\ -Recurse CHANGELOG.txt # Match expected

Scenario #2 - PackageReference does not work in the same way, unexpected

dotnet clean

dotnet remove .\B\ reference .\A\A.csproj

dotnet pack .\A\ -o .
nuget init . .\.nugetfeed\

dotnet add .\B\ package a

dotnet build

cat .\B\obj\project.assets.json | sls -Context 10 CHANGELOG # Matches expected, wrong configuration

The property copyToOutput is set to false, while true was expected based on <CopyToOutputDirectory>Always</CopyToOutputDirectory>.

ls .\B\bin\ -Recurse CHANGELOG.txt # No matches, buggy

Workaraound for Scenario #2

By editing nuget.spec manually in the generated package and adding file copyToOutput=true where required, the expected result can be achieved.

Expected Behavior

The Content files should always be copied to the output directory in the consuming project when CopyToOutputDirectory is set to a value other than Never.

Actual Behavior

The Content files using CopyToOutputDirectory=Always are not copied to the output directory in the consuming proejct when the dependency is declared as a PackageReference.

In this case, the corresponding nuget.spec file element lacks a copyToOutput property set to true, so the default false applies. It is expected that the copyToOutput property is set to true in this case.

By manually editing nuget.spec after package creation and adding copyToOutput=true for file elements, the desired behavior can be achieved using the otherwise exactly same package.

References

Analysis

  • Lacking documentation does not explain how to obtain the desired result in a NuGet package when using Content in a .xproj file to always output files to the consuming project's output directory.
  • Bug in Content when CopyToOutputDirectory is set to a value other than Never in PackageReferece-based dependency declarations.
  • Missing CopyToOutput boolean property in Content that mirrors file>copyToOutput property in nuget.spec. (Seems redundant when CopyToOutputDirectory exists.)

However, given that the expected result can be obtained when using Project to Project references, this issue appears to be a bug.

Versions & Configurations

.NET info

dotnet --info

Output:

.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.c6f19616
 MSBuild version:   17.12.7+5b8665660

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22631
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100\

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: x64
  Commit:       9d5a6a9aa4

.NET SDKs installed:
  9.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Note: The same problem can be observed in earlier versions of .NET.

@maridematte
Copy link
Contributor

This issue was moved to NuGet/Home#13993

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants