PublishSingleFile adds unwanted dependencies in 10.0.200

[lcsondes]

Describe the bug

A project that I'm working on broke when the .NET SDK was updated to 10.0.200, due to an unexpected and unwanted reference to Microsoft.AspNetCore.App.Runtime.win-x64. I've managed to narrow the issue down to PublishSingleFile.

To Reproduce

Start with an empty directory, and run dotnet new console. Create a file called nuget.config right next to the .csproj, with this content:

<configuration>
  <packageSources>
    <clear />
  </packageSources>
</configuration>

This is to ensure that nothing gets downloaded or restored in the background, and to make the dependencies visible. In the larger project where this issue was discovered, there is an <add> directive that points to a local collection of .nupkgs, which does not include ASP.NET Core, because nothing uses it.

Run dotnet build. The project will build successfully, which is a little surprising, but OK. Edit the .csproj, adding this line to its PropertyGroup: <PublishSingleFile>true</PublishSingleFile>

This will break the build:

error NU1100: Unable to resolve 'Microsoft.NET.ILLink.Tasks (>= 10.0.4)' for 'net10.0'.
error NU1100: Unable to resolve 'Microsoft.NET.ILLink.Tasks (>= 10.0.4)' for 'net10.0/win-x64'.
error NU1100: Unable to resolve 'Microsoft.NETCore.App.Runtime.win-x64 (= 10.0.4)' for 'net10.0'.
error NU1100: Unable to resolve 'Microsoft.WindowsDesktop.App.Runtime.win-x64 (= 10.0.4)' for 'net10.0'.
error NU1100: Unable to resolve 'Microsoft.AspNetCore.App.Runtime.win-x64 (= 10.0.4)' for 'net10.0'.

If you wish, you may download microsoft.netcore.app.runtime.win-x64.10.0.4.nupkg from NuGet, place it next to the .csproj, and edit nuget.config so that it's picked up (<add key="local" value="." />). This will remove its corresponding error, as expected, but AspNetCore and WindowsDesktop should not be required to build a trivial command-line hello world.

If the same steps are performed in 10.0.103, there's only one error:

error NU1100: Unable to resolve 'Microsoft.NET.ILLink.Tasks (>= 10.0.3)' for 'net10.0'.

The regression is the three new App.Runtime NU1100 errors being added to the set.

Exceptions (if any)

None

Further technical details

details of dotnet --info

.NET SDK: Version: 10.0.200 Commit: 40cd698e5c Workload version: 10.0.200-manifests.b7278506 MSBuild version: 18.3.0-release-26119-122+40cd698e5

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

.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.4
Architecture: x64
Commit: 80d3e14f5e

.NET SDKs installed:
10.0.200 [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.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.4 [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.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.4 [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.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.14 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.4 [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:
DOTNET_CLI_TELEMETRY_OPTOUT [1]

global.json file:
Not found

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

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

[koyote]

As a sort of meta question:

Does the above imply that a machine requires internet access to build a .net project as a single file (in order to download the dependencies from nuget)?

[marcpopMSFT]

This is not new in 10.0.200. Building for singlefile, selfcontained, or AOT requires various packs that are not included in the .NET install by default. This was done for size reasons as the various runtime packs can be large and they are different per architecture so including them all in the installer would be fairly large when most customers don't require most of those packs.

Today single-file implies self-contained in many scenarios but it's possible to build non-self-contained single file though that will still require the ILLink Tasks. I think there's an argument for including that in the SDK as it's a relatively small package.

CC @agocke @dsplaisted @baronfel @MichaelSimons

[agocke]

I’m skeptical we should be requiring all these targeting packs. We should know at restore time when if the project is trimmed or self contained.

As to the ILLink pack: it’s TFM-specific

[agocke]

Oh, we probably need ILLink in this case because that’s where the analyzer is. No idea why we need windows desktop.

[lcsondes]

If I downgrade to the 10.0.103 SDK and perform the same steps, the only error is

error NU1100: Unable to resolve 'Microsoft.NET.ILLink.Tasks (>= 10.0.3)' for 'net10.0'.

This package can be managed with NuGet CPM (after a little trickery), which made it fairly stable. There is a copy of it in the local collection of .nupkgs, and single-file builds work offline, even after %homepath%\.nuget is wiped clean. It not being required would be an improvement, but it isn't a regression.

The new App.Runtime packages have resisted all my attempts to pin a particular version, and suddenly depending on ASP.NET Core doesn't make sense anyway. For now, everyone affected has rolled back, which is not ideal. As I understand, .200 has security fixes, but they matter little if the build is broken.

[lcsondes]

@marcpopMSFT @agocke I've edited the report to highlight that the regression is the three new App.Runtimes, not ILLink. That's new in 10.0.200, please compare it against the output from 10.0.103 that I've posted above.

[baronfel]

It looks like in ProcessFrameworkReferences, we always add all TFM-and-RID-relevant Packs for all KnownFrameworkReferences (the set of data that the SDK knows about), without filtering this set down to the FrameworkReferences that are relevant to this specific project being built/restored.

This seems wrong on its face. This apparent regression came about because in the 200-series we fixed some holes in our "restore should get all necessary runtime-specific packs" logic, which is activated in part when single-file modes are requested - the single-file apphost is by necessity RID-specific.