Nugetgallery: Download counts are not updated for XrmLibrary packages

[skofman1]

https://www.nuget.org/packages/XrmLibrary.EntityHelpers.2015/
https://www.nuget.org/packages/XrmLibrary.EntityHelpers.2016/

probably because the package ends with a number, and stats pipeline can't parse the name properly.

[scottbommarito]

An additional package:

https://www.nuget.org/packages/XrmLibrary.ExtensionMethods.2016/

Also, XrmLibrary.ExtensionMethods appears to have download counts for XrmLibrary.ExtensionMethods.2016. It has package downloads for version 2016.1.0 on its package statistics page.

We should whitelist these packages and then they should begin tracking package downloads.

[skofman1]

@scottbommarito , can we update the whitelist and deploy the job as part of this sprint?

[emregulcan]

dear @skofman1 and @scottbommarito thank you for your help. I've a question, what is your sprint duration? when will fix this issue?

[skofman1]

@emregulcan , our sprint lasts 3 weeks, and the fix for your package will be deployed Wednesday.

[emregulcan]

@skofman1 thanks.
does your fix include any change for my current faulted counting or my counts'll be right and counting from zero after fixing

[skofman1]

@emregulcan , it will be counting from 0.

[emregulcan]

@skofman1 thank you.

[scottbommarito]

Just verified that the downloads are updating as expected!

[emregulcan]

Hi @scottbommarito, @skofman1
Thank you all about your interest and helps. I see counts are working (display +1), otherhand can we "merge" faulted counts on
https://www.nuget.org/stats/packages/XrmLibrary.ExtensionMethods?groupby=Version
As you can see it displays XrmLibrary.ExtensionMethods and XrmLibrary.ExtensionMethods.2016 (they're different packages) on same page

[skofman1]

@emregulcan , we will investigate the issue. In general, package ids that end with a dot and a number, don't parse well in our statistics pipeline. The reason is that we don't know if the number at the end is part of the version or part of the id.

[emregulcan]

Hi @skofman1 ,
As I ask/told before, if will be less painful than patching something and waiting sprints maybe we should remove my all packages which has this issue.
I can prepare and re-upload my packages with new package IDs without dot and number.
what do you think?
My package list;

XrmLibrary.ExtensionMethods
XrmLibrary.ExtensionMethods.2016
XrmLibrary.EntityHelpers.2015
XrmLibrary.EntityHelpers.2016

[skofman1]

@emregulcan , that would be great. You can unlist the existing packages, so they won't show up in search results and upload new packages instead, as you suggested.

[emregulcan]

@skofman1, actually "hard-delete" is perfect for me than unlist command, can you do that?

[skofman1]

@emregulcan , we reviewed your request and we reserve package delete for extreme scenarios, since it potentially breaks package consumers. Your scenario does not meet the criteria defined by our policy: https://docs.microsoft.com/en-us/nuget/policies/deleting-packages

[emregulcan]

@skofman1 , I see, so I think we've 2 options.

• my side : unlist packages and re-upload with different Ids
• your side : bugfixing and sprint release.

actually you solved one of my problems and main packages counting normally (at least I think that :))

what is your recommendation?

[skofman1]

@emregulcan , this is the plan. We will work on fixing this page: https://www.nuget.org/stats/packages/XrmLibrary.ExtensionMethods?groupby=Version

[emregulcan]

Hi @skofman1 , thank you and I'm waiting your response.
I think I broke NuGet :)

[agr]

Hi, I had updated the database, the download counts for packages should update in next few hours (up to 24)

[emregulcan]

Hi @agr , Thank you for yoru effort. one more question / wish, can you merge download counts at https://www.nuget.org/stats/packages/XrmLibrary.ExtensionMethods?groupby=Version in a single (v1.0) graph?

[agr]

The counts are now updated, all XrmLibrary.ExtensionMethods v2016.1.0 downloads were moved to XrmLibrary.ExtensionMethods.2016 v1.0.0.

[emregulcan]

Hi all,
Thank you for your support.
regards