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 44c5cb3 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?