Add per-package analytics to help library authors make platform decisions

[dotMorten]

Feature Request:

As a library author, it can be really difficult to gain insight into how your nuget package is being used. For instance, if I'm targeting UWP, can I drop support for the 10240 SDK? Can I drop support for .NET 4.5.2 and move to .NET 4.6.1? Or is it OK to move from .NET Standard 1.4 to 2.0? Do I really need to support Windows Phone 8.1 still? Should I spend time on testing my .NET Standard package on Tizen or is its use negligible?

I would suggest that when a developer adds or restores a nuget package from nuget.org, when it is possible, the request headers includes information about the project it's being added to. Ie project type, platform version, VS version etc. This information is then recorded, and the library author will be able to log in and get aggregated statistics about how the package is being used by other developers, and the trends over time.

[emgarten]

This looks very useful, we'll discuss it on the team and see what we can do to surface this data to package authors.

[jariq]

I don't say that I don't agree with OP but another currently feasible approach would be to split package with assemblies for multiple platforms into multiple packages each containing assemblies for a single platform.

Let's take my Pkcs11Interop package as an example:

This single package currently contains assemblies for net20, net40, net45, sl5, netstandard1.3, monoandroid2.3 and xamarinios1.0 platforms. However it could be split into 7 independent packages Pkcs11Interop.net20, Pkcs11Interop.net40, Pkcs11Interop.net45, Pkcs11Interop.sl5, Pkcs11Interop.netstandard1.3, Pkcs11Interop.monoandroid2.3 and Pkcs11Interop.xamarinios1.0.

Setup like this would provide detailed platform statistics to the package author and to any interested 3rd party as number of package downloads is publicly available. Developer who consumes the package would download only assemblies he really needs and would not "pollute" his solution.

Similar approach is very common in Linux packaging systems. There is a separate binary package for x86 architecture, separate binary package for amd64, separate binary package for arm etc. NuGet is actually the only packaging platform I know that ships binaries for multiple platforms in a single package.

[maartenba]

NuGet 2 had X-NuGet-... headers that shipped that info. These are long gone, which is a pity.

NPM sends a boatload of this info, which is nice. It even tracks what package was dependent, so that you can also learn which packages bring along some of your own.

Example NPM request headers (bold emphasis):

GET http://registry.npmjs.org/angular HTTP/1.1 accept-encoding: gzip version: 4.4.0 accept: application/json referer: install angular npm-session: 477ae8411731f4af npm-in-ci: false user-agent: npm/4.4.0 node/v6.10.0 win32 x64 host: registry.npmjs.org Connection: keep-alive

When a dependency is fetched, the referer also contaisn the original install command so you know the "root" of the tree.

+1 on this, would be good to have this info

[dotMorten]

@jariq so you're saying, if I have a .NET Standard 1.0 package which will run on a gazillion combinations of project types, frameworks and platforms, I should go through the enormous hazzle of splitting it out into platform/framework specific sub-packages just to do this? And if a new .NET Standard platform comes along tomorrow, I'll have to add that too? I prefer my suggestion to that 😄

[jariq]

@dotMorten for me personally nestandard* moniker/platform still indicates only .NET Core support so I did not think about that case. You are right that once we get to the state where netstandard* is all you need for all the different project types then your solution will be superior to mine so I'm giving 👍 to your suggestion 😉

[timheuer]

Why NuGet telemetry? Why not just binary analytics? This would actually get you usage telemetry that I think matters more than just what is in the IDE usage (or at least a more realistic correlation).

[dotMorten]

Binary analytics works for apps. It doesn't really work for 3rd party libraries. They also serve two different purposes. One tells you something about the environment the developer chooses to use, the other about the environment the end user runs it on. Both can be important but they are distinctly different. Also a lot of apps aren't run connected, so gaining insight into what type of targets the product is used on helps me determine where to put some testing effort which .Net standard hides (could run anywhere I didn't think of at all), and also helps determine nuspec version I can move to, project templates support etc.

[maartenba]

See above comment on headers. That's what used to be there before v3.