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

Consider removing the extensibility that allows other package managers to be shown as compatible #6623

Closed
nkolev92 opened this issue Feb 28, 2018 · 4 comments · Fixed by NuGet/NuGet.Client#4203

Comments

@nkolev92
Copy link
Member

Create any PR/PJ based project and open the PM UI and see that there's a

Incompatible: Use Bower instead

when we list those packages.

This is achieved with an extensibility point that allows other "alternative" managers to talk to NuGet and advertise if they're the preferred option for those packages.
Code here.

The reason why these packages are incompatible is because they contain content, the mutable v2 kind.
However, if you read the ASP.NET docs, there's conflicting information.

These 2 packages are perfect examples of what contentFiles should be used for.

We should consider removing this "AlternativePackageManagerProviders" goo, and work with the jquery/bootstrap nuget package maintainers to make these 2 packages PR compatible.

@nkolev92
Copy link
Member Author

nkolev92 commented Apr 18, 2018

Another customer filled a similar issue to this one:
https://developercommunity.visualstudio.com/content/problem/225023/aspnet-core-web.html
//cc @rrelyea
This a part of the ASP.NET projects should support PackageReference effort.

@StingyJack
Copy link
Contributor

We should consider removing this "AlternativePackageManagerProviders" goo, and work with the jquery/bootstrap nuget package maintainers to make these 2 packages PR compatible.

Or you should consider that in some cases we need to be able to modify the content that would be distributed by the package into our project to address issues with it or for any other reason. Its frustrating to be held hostage to a bug that you can correct, but are artificially forbidden from doing so. Tools should enable, not restrict.

@nkolev92 nkolev92 added Sprint 153 Triage:NeedsTriageDiscussion and removed Priority:2 Issues for the current backlog. labels May 21, 2019
@nkolev92
Copy link
Member Author

//cc @rrelyea
The existence of this is not allowing us to fixed certain delays in the PM UI construction ~50ms to 100ms depending on the load.
Basically the below method is foced to be synchrnous https://github.com/NuGet/NuGet.Client/blob/5c2db09662f99d96a47182b761fcea6df1625a5a/src/NuGet.Clients/NuGet.Tools/NuGetUIFactory.cs#L75 since some methods in the implementers rely on being called on the UI thread https://github.com/NuGet/NuGet.Client/blob/5c2db09662f99d96a47182b761fcea6df1625a5a/src/NuGet.Clients/NuGet.PackageManagement.UI/Utility/PackageManagerProviderUtility.cs#L11.

Basically I can't make this method async.
This is obviously an implementation bug on Bower side.

We should retriage it again.

@donnie-msft donnie-msft moved this from High priority to Needs triage in VS PMUI Triage Aug 12, 2021
@donnie-msft
Copy link
Contributor

Related (now closed) bug I filed dotnet/aspnetcore#27480

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

5 participants