-
Notifications
You must be signed in to change notification settings - Fork 645
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
Add config option to show the nuspec title field in NuGet.Server's OData title field instead of package ID #9010
Comments
This seems like a NuGet.Server problem. Moving to the gallery repo. |
@D4N4M8 thanks for the detailed bug report. I am not sure if this is specific to NuGet.Server. Could you try your sample app against NuGet.org's V2 endpoint? i.e. If you query for a package like Newtonsoft.Json, which has a title field of I am thinking this may be an expected behavior of the client SDK (e.g. NuGet.Protocol). There has been a long running effort to move away from using the Anyhow, please try against NuGet.org with a package having a set One possible route would be for you to open a PR against the NuGet/NuGet.Server repo which allows this behavior to be changed from configuration, e.g. a "UseTitleAsODataTitle = true | false" setting. |
@joelverhagen: Thank you for your quick reply. I tested it again with the NuGet.org's V2 endpoint. Your guess is correct. The behavior is identical (see attached screenshot). Do you close this issue or how do we proceed with this? Greetings Daniel |
You can keep this issue open until that PR is merged. Typically we have a tracking issue for all PRs. This issue can be the tracking issue for the NuGet.Server PR. |
Is there any progress in this issue? |
NuGet Product Used
NuGet.exe, NuGet SDK
Product Version
NuGet.Protocol (6.1.0)
Worked before?
No response
Impact
It's more difficult to complete my work
Repro Steps & Context
I'm in the process of transitioning from a local NuGet feed to a self-hosted NuGet server. I encountered a problem when testing the self-hosted NuGet server, which affects the NuGet packages or the NuSpec files: The "GetMetaDataAsync" method and the "SearchAsync" method do not return the title of the NuSpec file or the NuGet package in the "title" field of the "IPackageSearchMetadat" object. Apparently the "ID" is returned in the "Title" field.
I use the "title"-field in the installation process of my packages to display less technical text to the end-user. Of course I could use the "description"-field as a temporary solution, but then I don't have this field for a detailed description.
The following steps must be carried out to reproduce the error:
Create and start your own NuGet.Server (Link: https://docs.microsoft.com/en-us/nuget/hosting-packages/nuget-server)
Create a NuSpec-File.
Build the nuget package and add it to your nuget server.
Check if the package is in the packages folder.
Open the NuSpec file of your package, which is located on the NuGet server, in a text editor and check the "id"-, the "title"- and the "description"-field.
Create a console application (e.g. with NET 6.0) and install the NuGet package "NuGet.Protocol" (version 6.1.0)
Connect your console application to your NuGet server (packageSource) and search your NuGet package by package id (e.g. MyId000123).
Write the "ID", "Title" and "Description" to your console window via the WriteLine method.
Problem:
The "GetMetaDataAsync" method and the "SearchAsync" method do not return the title of the NuSpec file or the NuGet package in the "title" field of the "IPackageSearchMetadat" object (siehe screenshot)
Analyse:
The NuSpec title is returned correctly via a GET request.
I think the error happens on client side. Probably inside the "V2FeedParser.cs" class. The XML structure is converted into the internal object in the "ParsePackage" method. I think the wrong "Title" element is being mapped here.
I hope I described the error sufficiently and it's okay that I didn't upload any example applications.
I look forward to feedback!
Best regards Daniel
Verbose Logs
No response
The text was updated successfully, but these errors were encountered: