-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to build the project locally #728
Comments
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. |
Yep, it builds now thanks. I'll keep an eye out for those transition periods |
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:
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? |
When package dependency versions change, the libman package feed (hosted on the azure-public ADO instance) is not writable by non-Microsoft employees. This can lead to issues building the solution when adding/updating references, especially including when runtime packages update from SDK servicing. This change fetches any publicly available packages from nuget.org, which makes it easier to support new packages or package upgrades. Having multiple package sources is not a risk when using packageSourceMappings. Resolves aspnet#728
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:
dotnet restore
Expected behavior
Project restores dependencies successfully
Screenshots
Additional context
Visual Studio 17.9.2
Dotnet SDK 8.0.200
The text was updated successfully, but these errors were encountered: