dotnet restore is unable to find common .NET packages since switching to .NET 5.0

Description

I switched from .NET Core 3.1 to .NET 5 and since then the action fails to restore common .Net packages.

Details

Error messages on installing dependencies “dotnet restore Project.sln”. The error does not occur when the command is executed locally. No custom nuget repository is used and the packages should be available.

error NU1101: Unable to find package System.Memory. No packages exist with this id in source(s): github [/home/runner/work/Project/Project.sln]
error NU1101: Unable to find package System.Numerics.Vectors. No packages exist with this id in source(s): github [/home/runner/work/Project/Project.sln]
error NU1101: Unable to find package NETStandard.Library. No packages exist with this id in source(s): github [/home/runner/work/Project/Project.sln]

name: .NET Core

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Setup .NET
      uses: actions/setup-dotnet@v1.7.2
      with:
        dotnet-version: 5.0.100
    - name: Install dependencies
      run: dotnet restore Project.sln
    - name: Build
      run: dotnet build Project.sln --configuration Release --no-restore
    - name: Test
      run: dotnet test Project.sln --no-restore --verbosity normal

[csinkers]

Adding a NuGet.config is a better way to fix it, e.g.

<configuration>
  <packageSources>
    <!--To inherit the global NuGet package sources remove the <clear/> line below -->
    <clear />
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

[csinkers]

The details for why it broke and why a nuget.config fixes it are pretty complicated, if you follow the links from this issue to the various ones that got raised in the github actions, .net core, and nuget repositories you can get the whole story.

I think it boiled down to a change in some nuget rule that ended up (sporadically) breaking things for every project that didn’t have an explicit nuget config, and while the nuget change would normally be benign, some detail of the GitHub actions environment meant it caused issues.

Because it was only partially the fault of either project I think neither took responsibility for fixing it, so we all have to be explicit about our nuget sources using a config now 😕