Unable to build the project locally

[MatthewSteeples]

Describe the bug

Doesn't look like those of us outside of Microsoft can access the Azure Artefacts feed that this project depends on.

To Reproduce

Steps to reproduce the behavior:

1. Check out the project
2. Run dotnet restore

Expected behavior

Project restores dependencies successfully

Screenshots

error : Failed to download package 'Microsoft.NETCore.App.Hos
t.osx-x64.6.0.27' from 'https://pkgs.dev.azure.com/azure-public/0b6653b2-b704-470b-94ed-d0e2e194a663/_packaging/5d2fa05
1-5b55-432e-849e-a04a0d44a500/nuget/v3/flat2/microsoft.netcore.app.host.osx-x64/6.0.27/microsoft.netcore.app.host.osx-x
64.6.0.27.nupkg'

Additional context

Visual Studio 17.9.2 Dotnet SDK 8.0.200

[jimmylewis]

I'm currently able to restore cleanly from a non-Microsoft computer. I think it's a point in time issue: with #729 the feed was populated with all the current packages. However, a future .NET SDK servicing release could cause one of the runtime packages (such as microsoft.netcore.app.host.osx-x64 mentioned above) to be bumped to a newer version; that then requires that an authorized user push that package into the libman feed (i.e. the point in time can and will come up again).

I tried going back to before we had the consolidated feed in #731. It failed because some of the internal packages are no longer available on the msft_consumption feed. It does, however, benefit from having the dotnet-public feed in the list, which would be populated with any newly serviced packages in the future.

So, one fix would be to do something like https://github.com/aspnet/LibraryManager/pull/731/commits/44c5cb32c2449a81df7ab2b2e4b03ca141eca2d6 where it uses the dotnet-public feed for runtime packages, and uses the libman feed for vs-internal packages (the dotnet-myget-legacy can also probably be dropped if using the libman feed). Maybe revive the PR if that seems like an appropriate way to address the problem...

There's still a potential issue that any external contribution that wants to adopt a new package not present in the dotnet-public feed would be unable to have a successful PR builds without some intervention - without authorization to push new packages into the libman feed, the CI build would fail.

As a workaround, external users can add nuget.org locally to be able to restore any public packages. However, I know the policies for MSFT CI builds is to use authenticated feeds as much as possible.

/cc @phil-allen-msft for all this context.

[MatthewSteeples]

Yep, it builds now thanks. I'll keep an eye out for those transition periods

[jimmylewis]

Lo and behold, I ran into this issue again already trying to adopt a new package that was on nuget.org but not in the libman feed. I ended up working around it by replacing my local nuget.config with:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="libman" value="https://pkgs.dev.azure.com/azure-public/vswebtools/_packaging/libman/nuget/v3/index.json" />
  </packageSources>
  <packageSourceMapping>
    <packageSource key="libman">
      <package pattern="*" />
    </packageSource>
    <packageSource key="nuget.org">
      <package pattern="The library I was trying to use" />
    </packageSource>
  </packageSourceMapping>
</configuration>

If I was trying to adopt a library with many dependencies, I'd probably have to list each of those as a package pattern, unless they were already in the feed (at presumably the exact version). That'd be even more tedious to try to get right.

Even worse, when I send a PR, the build does indeed fail, and there's no workaround aside from having an authorized user get the necessary packages into the feed and requeuing the build.

@phil-allen-msft this is really frustrating to have to work around when trying to make a new contribution. Can you look into what the right way to handle this would be?