PackageReference System.ValueTuple will not be pruned

[ManickaP]

Cannot build System.Net.Http / Quic projects with dotnet build due to:

  Determining projects to restore...
/home/manicka/repositories/runtime/src/libraries/System.Formats.Asn1/src/System.Formats.Asn1.csproj : error NU1510: Warning As Error: PackageReference System.ValueTuple will not be pruned. Consider removing this package from your dependencies, as it is likely unnecessary. [/home/manicka/repositories/runtime/src/libraries/System.Net.Http/System.Net.Http.slnx]
  Failed to restore /home/manicka/repositories/runtime/src/libraries/System.Formats.Asn1/src/System.Formats.Asn1.csproj (in 484 ms).
  101 of 102 projects are up-to-date for restore.

Build FAILED.

/home/manicka/repositories/runtime/src/libraries/System.Formats.Asn1/src/System.Formats.Asn1.csproj : error NU1510: Warning As Error: PackageReference System.ValueTuple will not be pruned. Consider removing this package from your dependencies, as it is likely unnecessary. [/home/manicka/repositories/runtime/src/libraries/System.Net.Http/System.Net.Http.slnx]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:05

It doesn't seem to be a problem of System.Formats.Asn1.csproj, that file hasn't changed in a while.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[ViktorHofer]

Please post the dotnet info output so that we know which commit the SDK in use is based of.

[ViktorHofer]

NuGet complains about this line: https://github.com/dotnet/runtime/blob/f87bc538de38f5ef1094a093b9f9154e7d9b3d16/src/libraries/System.Formats.Asn1/src/System.Formats.Asn1.csproj#L70

But package pruning shouldn't be enabled for .NET Framework...

[ViktorHofer]

You can also send me a binlog offline so that I can take a look.

[ManickaP]

dotnet --info                                                                                                                                                                                      1 
.NET SDK:
 Version:           10.0.100-rc.2.25454.107
 Commit:            96384f4628
 Workload version:  10.0.100-manifests.5380e3b6
 MSBuild version:   17.15.0-preview-25454-107+96384f462

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  22.04
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/10.0.100-rc.2.25454.107/

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.0-rc.2.25454.107
  Architecture: x64
  Commit:       96384f4628

.NET SDKs installed:
  8.0.316 [/usr/share/dotnet/sdk]
  9.0.108 [/usr/share/dotnet/sdk]
  10.0.100-rc.2.25454.107 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.18 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.6 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0-rc.2.25454.107 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.18 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.6 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0-rc.2.25454.107 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_CLI_TELEMETRY_OPTOUT              [1]
  DOTNET_LTTng                             [0]

global.json file:
  /home/manicka/repositories/runtime/global.json

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

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

[ericstj]

I was able to reproduce this problem, it only occurs with the RC2 build @nkolev92 @dsplaisted.

I can reproduce it by directly restoring the System.Formats.Asn1 project as well.

It looks like this has to do with a multi-targeting project, where one TargetFramework targets netfx.

I have a simplified repro, I get no warning when targeting only net462 but get a warnings when targeting net10.0;net462.
The same project gives no warnings at all with SDK version 10.0.100-rc.1.25411.109
tuplePrune.zip
binlogs.zip -- contains both a RC1 and RC2 binlog showing the differences.

I think this has to do with changes around _RestorePackagePruningDefault -- have a look at this difference (right side is RC2).

I'll add a workaround to arcade to unblock folks using the RC2 SDK.

If anyone else is hitting this you can set:

  <PropertyGroup>
    <!-- Workaround https://github.com/dotnet/runtime/issues/119387 --> 
    <RestoreEnablePackagePruning Condition="'$(TargetFrameworkIdentifier)' == '.NETFramework'">false</RestoreEnablePackagePruning>
  </PropertyGroup>

[baronfel]

IRIC we changed pruning to enable for all TFMs as soon as you targeted any 10+ TFM at all in a project, so this feels like expected behavior to me? Implementation (and link to spec) was at #50348.

[ericstj]

No need for a workaround here for us, since it looks like @ViktorHofer already addressed this in dotnet/arcade#16102. It seems the bug was hit in dotnet/dotnet#2037 when rebootstrapping a newer RC1 build. @ManickaP you'll get this fix once runtime picks up the latest backflow from dotnet/dotnet dotnet/runtime#119379 (update, actually that backflow didn't contain the fix, will need one more and we don't yet have a build of dotnet/dotnet with the changes).

@baronfel - I thought we agreed to never enabling pruning for .NETFramework since those packages are a bit more "special" in how things land (app-local, bindingRedirects, etc).

Options moving forward:

1. Don't enable pruning on .NETFramework at all.
2. Enable it, but don't raise any packages to prune.
3. Adjust all the packages to prune to represent the cases where they were added to the targeting pack (and weren't just part of Microsoft.NET.Build.Extensions).

[dsplaisted]

We may have said we didn't want to enable pruning on .NET Framework by default (I can't remember for sure), but that was probably lost when we decided to enable pruning for all frameworks if any of them targeted .NET 10 or higher.

@nkolev92 Thoughts about what we should do?

[nkolev92]

The primary selling point of pruning, and why we were originally comfortable with enabling it in a lot of scenarios by default, was that if you enable this feature, your project will work exactly the same, but you'll get fewer warnings and better perf.

If we provide data that breaks these promises, it feels like that data is in a way wrong incorrect.

My suggestion would be to not raise packages to prune, so 2 from Eric's list.
I'm not sure if 3 is visible without big changes and I'd love to get it out the door before we would make any of those.