NuGet gallery UI should also show compatible runtimes and not just target frameworks

[yishaigalatzer]

See https://github.com/NuGet/Home/issues/1688

[maartenba]

@emgarten Any hints on an API to determine this info?

[emgarten]

Finding them for the lock file is here: https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Commands/LockFileUtils.cs#L153-L180

RIDs would need to be shown in the context of a TxM since that is selected first. Note also that RIDs come from the packages and are just opaque strings and their meaning comes from other packages in the graph that contain runtime.json files. NuGet doesn't understand RIDs today like it understands frameworks.

[maartenba]

So in terms of the gallery we'd need to build the dependency graph and go from there?

[emgarten]

You would only need the graph if you need to do actual RID compatibility checks. To just display the available ones you can go by the folder paths.

[maartenba]

Any sample on making this into a human-readable format?

[emgarten]

They are usually readable, they just can't be parsed. There is no syntax for these strings.

For example with frameworks we know that net45 is RIDs usually look like: win10-x86 but there is no set format to allow them to be parsed

[maartenba]

So basically this?

• Loop the lib folder's first-level childs
• If it's a folder, check if we have a known framework for it
• If not, it's a runtime and we can treat it as such

[emgarten]

No, TxMs and RIDs are not used interchangeably under the lib folder in that way. You'll need to parse them using the content model and managed code conventions in the NuGet.Client project.

[maartenba]

Have a quick example somewhere? (eg a unit test?)

[AArnott]

NuGet gallery UI should also show ... not just target frameworks

It doesn't even do that. It only shows the target frameworks of dependencies. Not the package itself.