Nugetgallery: Show statistics for target package is restored for

[twsouthwick]

Generally, packages should not have a separate package for a target (such as .NET 4.0) but instead have it as another dependency within the package. However, by keeping it separate, statistics about usage can be easily seen (ie - how many people are using the .NET 4.0 version). Is there a way to add visualization for that to the website (or some other way to get at that data)?

[skofman1]

@xavierdecoster ?

[xavierdecoster]

I don't think we can offer a solid story today in response to this question based on the download data we already collect and use to show statistics. The server doesn't know about the target framework selected by the client.

As for showing what package caused the dependent package to be installed: I think older or NuGet.Core-based clients do send this information in custom HTTP-headers (e.g. NuGet-Operation, NuGet-DependentPackage, and NuGet-DependentPackageVersion), but not sure about support in v3 protocol and newer clients.

Either way, the stats processing pipeline does not collect that information today.

@rrelyea this may be a good candidate for client telemetry?

[reisenberger]

Thanks @xavierdecoster for feedback. @twsouthwick has also suggested a workround for us to maintain both a unified package (for users) and split-out package (for stats) at the same time.

@xavierdecoster Not sure if related, but our Nuget package stats broke around the time this was investigated: the Total Downloads figure went up just one from 450,947 to 450,948, then has stuck at that for 5 days or so. This is unfeasible: we wouldn't just drop from >300 downloads/day to zero. Could our stats feed have been broken, by someone checking out this issue?

(Raising here as frozen stats co-timed with this issue - but let me know if you want a separate card)

( /cc @joelhulen for info )

[xavierdecoster]

@reisenberger thanks for raising. However, as an FYI, the stats not being updated currently is unrelated to this issue (timing is a coincidence), and is already being investigated at the moment.

[reisenberger]

Thanks @xavierdecoster @skofman1 for your input and help.

[rprouse]

I manage the NUnit package which is very popular and has many targets. It would be extremely useful to us to know which target frameworks users install our package for. Our code base is overly complicated by the number of targets we support, so full stats would allow us to drop support for .NET frameworks with low usage.