Skip to content
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

Build an async IVsPackageSourceProvider service #8902

Open
Tracked by #8872
kartheekp-ms opened this issue Dec 10, 2019 · 5 comments
Open
Tracked by #8872

Build an async IVsPackageSourceProvider service #8902

kartheekp-ms opened this issue Dec 10, 2019 · 5 comments
Labels
Functionality:SDK The NuGet client packages published to nuget.org Priority:2 Issues for the current backlog. Product:VS.Client Tenet:Performance Performance issues Type:Feature

Comments

@kartheekp-ms
Copy link
Contributor

Child task for #8675

@kartheekp-ms kartheekp-ms self-assigned this Dec 10, 2019
@kartheekp-ms kartheekp-ms changed the title UI delay spec work (review spec internally and with partners) Design an async IVsPackageSourceProvider services Jan 3, 2020
@nkolev92 nkolev92 removed the Cost 25 label Jan 6, 2020
@nkolev92 nkolev92 added Functionality:SDK The NuGet client packages published to nuget.org and removed NuGet API labels Apr 24, 2020
@nkolev92 nkolev92 changed the title Design an async IVsPackageSourceProvider services Build an async IVsPackageSourceProvider service May 20, 2020
@nkolev92 nkolev92 added Tenet:Performance Performance issues Priority:2 Issues for the current backlog. labels May 20, 2020
@nkolev92
Copy link
Member

Discussed in #9811 and https://github.com/dotnet/roslyn/pull/46022/files#r456003371 since it causes UI delays.

@zivkan
Copy link
Member

zivkan commented Jul 16, 2020

FWIW, I don't support making an async version of IVsPackageSourceProvider as a direct port. From an API design point of view (think of the developer experience using the API), it's weird that we have a service/provider that does nothing more than get sources. It harms API discoverability, as the developer needs to hunt to find what other interfaces NuGet exposes and whether those are useful to their project.

With GetInstalledPackages, I created a INuGetProjectService which should be suitable for all project-related APIs. I propose we consider creating a INuGetSolutionService for all solution APIs.

As I mentioned in the duplicate issue, PackageReference projects can have additional per-project sources. Therefore we should consider whether a replacement API is per-project, solution-wide, or if we create two APIs.

@nkolev92 nkolev92 removed the Priority:2 Issues for the current backlog. label Aug 15, 2020
@nkolev92 nkolev92 added the Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. label Aug 15, 2020
@nkolev92
Copy link
Member

pri3 according to @aortiz-msft

@nkolev92 nkolev92 added Priority:2 Issues for the current backlog. and removed Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. labels May 6, 2021
@nkolev92
Copy link
Member

nkolev92 commented May 6, 2021

I think there's still a need for this service, but the primary problem in #8675 is that the NuGet is being loaded on the UI thread, and that's something that's been fixed.

@nkolev92
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Functionality:SDK The NuGet client packages published to nuget.org Priority:2 Issues for the current backlog. Product:VS.Client Tenet:Performance Performance issues Type:Feature
Projects
None yet
Development

No branches or pull requests

4 participants