Open D4N4M8 opened 2 years ago
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. https://www.nuget.org/api/v2
If you query for a package like Newtonsoft.Json, which has a title field of JSON.NET
, I think you may see the same problem.
https://www.nuget.org/api/v2/Packages(Id='Newtonsoft.Json',Version='9.0.1')
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 title
attribute and use only the package ID. I think behavior in the client may be part of (or a side effect of) that broader effort.
Anyhow, please try against NuGet.org with a package having a set title
attribute and let me know if you run into the same problem. If you do, I think this is expected behavior and not a NuGet.Server bug.
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? I'm using 6.7 already and the mapping problem is still present. Usage of "UseTitleAsODataTitle = true | false" setting is not clearly described hire.
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