NuGet 3.4 breaking changes

Guest

Hi,

As of Visual Studio 2015 Update 2, the included NuGet client is version 3.4.1.807. Starting with 3.4, the NuGet client introduces some breaking changes in the version handling department: Normalized Version Numbers

I have an issue where if I install an internal package version 1.0.26.0 and then try to update it to the latest version (1.0.61.0), the client will try to do the following:

GET http://feeds.X.com/nuget/Packages(Id='X.Client.Common',Version='1.0.61')

Notice the missing ".0" at the end of the version. When I run this query manually, ProGet returns "Package not found.". The NuGet client does not receive a 404 and tries to parse the response as XML, but fails miserably as you can see here:

OK http://feeds.X.com/nuget/Packages(Id='X.Common',Version='1.0.61') 7ms
Update-Package : Error downloading 'X.Client.Common 1.0.61.0' from 'http://feeds.X.com/nuget'.
Data at the root level is invalid. Line 1, position 1.
At line:1 char:1
+ Update-Package X.Client.Common
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Update-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.UpdatePackageCommand

Install failed. Rolling back...
Package 'X.Client.Common 1.0.61.0' does not exist in project 'X.Common.NuGet'

So there are two issues here:

ProGet doesn't seem to support the new version handling
ProGet does not return a 404 when a package isn't found

If you need more info, don't hesitate to ask.

Thanks!

Product: ProGet
Version: 4.0.9

Guest

Thanks for the detailed information; for now, we will handle this by returning a 404; we believed that was never returned due to a quirk with some of the 1.x versions.

See GitHub Issue #2298 for more discussion on the topic as well.

Guest

Thanks for replying so fast and for the github link.

I'm glad to hear that you're aware of the issue and already have a start of solution.
Do you have a very rough timeframe of when that fix could be released?

Also, any news on the implementation of v3 API?

Thanks again!

Guest

We don't have an ETA on the v3 API; we will try to coordinate with the NuGet team to see when that would make sense for partners to start using it. Currently, no third-party tools use it, and the official clients will support v2 indefinitely.

Guest

I am having this exact issue in proget 4.1.1. If a package has a version of 1.0.0.0, nuget 4.0+ will request for version 1.0.0. Proget responds with a 500 internal server error. When can a fix be expected? This is breaking our capability of using package restore effectively between visual studio 2013 and visual studio 2015.

Guest

I apologize, I meant version 3.4+ of nuget, not 4.0

Guest

We've tried to reproduce this with ProGet 4.1.1 and NuGet 3.4, but haven't been able to get the 500. Is anything written to the ProGet error log? There should be a log message with a stack trace if there was a 500 returned by the server.

Guest

No, there is nothing logged in the proget event log.

Using fiddler, I am able to reproduce the error. I can also reproduce the error using a browser only since it is a GET request. Utilizing nuget.exe version 3.4.4.1321 also reproduced the issue.

Guest

App: Proget 4.1.1
OS: Windows Server 2012 R2
WebServer: IIS, using SSL with Trusted CA signed Certificate. Port 443.
SQL: SQL Server 2014 Standard

Proget is utilizing built-in accounts only and is not using LDAP/AD for authentication.

Added Ninject 3.2.2.0 to repository

Request https://{domain}/nuget/{feed}/Packages(Id='ninject',Version='3.2.2')
Generates 500 error

Request
https://{domain}/nuget/{feed}/Packages(Id='ninject',Version='3.2.2.0')
Generates 200 with xml response

Guest

This seems to be unrelated; the problem before was that ProGet was not providing a 404 when a package was not found, but instead an empty result.

Also, we cannot reproduce this error at all, so it's isolated to yours. As such, please Ask a New Question as not fill this one; and also make sure to provide a stack trace of the 500 error message; this can be found in Admin > Error Logs.