-
Notifications
You must be signed in to change notification settings - Fork 253
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
Package applicability in NuGet package manager - Search & Update by TFM #5725
Comments
Just some random thoughts having had this thing in a mind background thread. A first question would be: will this be a server-side or client-side thing? Or, as I would expect, both sides? Package metadata does not contain the relevant info required to make a decision whether to include/exclude a result, so this should be based on telemetry. Ideally, this telemetry is something that can be collected by all NuGet clients, e.g. NuGet.exe, dotnet.exe, VS, Rider, Paket, ... Ideally the format of this telemetry is a protocol extension (given this client-side The server can then use this context (ideally with a well-known decision tree?) and gather results that best match the query and search context. And then of course the other one to consider: privacy. What info can be legally shipped to the server to come up with a better result? |
With the spec now announced: see previous comment :-) |
(or: what is the Server-Side spec for this?) |
@maartenba this spec is focused on the end-user experience. Once we are close to finalizing that, we'll start a discussion around the implementation details. |
Thanks! Looking forward to seeing the technical spec later on. |
@karann-msft there are some asks on having the framework information on gallery too. Can you include that in your spec? If not, create a sibling spec that takes care of the gallery changes and search improvements both on the gallery and on VS UI. |
Based on the current proposal for GT, it'll need to consider the new package type as well. So tools would not get shown in the PM UI. |
@nkolev92 I don't think there would ever be a reason for GT packages to show up in PM UI, correct? Since they are not meant to be installed to project? |
@karann-msft Yeah, that's what I meant. |
@nkolev92 I will update this spec to call out that Tools packages will never be shown in the PM UI, but this should be tracked as part of the GT spec since GT packages are never applicable or compatible with any project and we should safeguard against it. |
@karann-msft Yep, that's already called out in the tools spec and implemented as such :) A similar ask came through #6484. No "actionables" here yet, before we narrow that down. |
Figured I'd chime in here instead of creating a new issue. I'd love to have a |
Hey all, A lot of this functionality will be server dependant. The good news is that we're looking into adding the respective support to nuget.org. Please take a look at #11374 and leave us any feedback you may have!
Just a small clarification, NuGet itself does not suggest/recommend updates. NuGet shows available updates. |
I had to dig in order to find out that version |
It should be noted that .NET 6 is LTS, and supported until November 12, 2024. .NET Core 3.1 and .NET 5 may legitimately be regarded as old, but .NET 6 certainly is not. So the experience of using it should, ideally, not be degraded in this way. |
@Bellarmine-Head this can be fixed by supporting allowedVersions like in packages.config. With this we could easily only see 6.0.x updates |
Thanks @MagicAndre1981 If you have some suggestions for Microsoft re. an easy fix for this, please do consider adding a comment to my other ticket (on the Microsoft side) for this issue:- |
As I said in my other ticket, imagine Windows Update offering you Windows 11 updates for your Windows 10 install... they fail to install and obscure genuine Windows 10 updates that you really need for security. The notion is laughable. Yet that is what is effectively happening here, re. .NET 6 packages. |
Is there any update on this issue? |
Hi friends, Small update. While there are general painpoints every major .NET release, we had to do some server work that we shipped recently to start to expand our options of providing a great experience where you get applicable packages on the client side. We are shipping another parallel effort that may help you fix these inconsistencies(blog coming soon), but largely this specific work stream will require a fresh set of eyes to the existing spec, perhaps a new experience proposed, and simplifying these experiences now that we have made NuGet more "TFM aware". We understand the current challenges with being prompted updates for new packages targeting incompatible TFMs and it will take some more time to make progress on this front. I know this isn't what you want to hear, but we're almost unblocked on the server side. |
Sounds like real progress @JonDouglas - thanks. Please do keep us posted on here, e.g. re your coming blog piece. |
Yes it sucks but we are moving in the right direction here. We're working on exposing the TFM APIs to the v3 api which will allow us to do something more here. |
again, until this larger TFM API issue is resolved give us allowedVersion attribute from packages.config back and we can hide the 8 packages in for example .net 6 branch @JonDouglas |
any updates on this? |
Status: Reviewing
The specification is available here:
Package applicability in NuGet package manager UI
The prerequisite for this issue is NuGet/NuGetGallery#3098. The implementation will start server side.
Client side discussions should happen on this issue.
This issue covers,
[To help searching for this issue: "Search by TFM" and "Update by TFM"]
The text was updated successfully, but these errors were encountered: