NuGet 3.4 fails to install package ending with zero #2298

NN--- · 2016-03-10T20:19:26Z

I have package "A" with version 1.1.1.0 .

Prior 3.4 this command works well:

nuget install A -version 1.1.1.0

With NuGet 3.4 RC I get:

An error occurred while retrieving package metadata for 'A.1.1.1' from source 'N'.
  An error occurred while retrieving package metadata for 'A.1.1.1' from source 'N'.
  Data at the root level is invalid. Line 1, position 1.

The text was updated successfully, but these errors were encountered:

emgarten · 2016-03-10T20:43:48Z

What type of source are you installing from? Online v2? Online v3? Local disk?

NN--- · 2016-03-10T20:44:38Z

I use ProGet server (http://inedo.com/proget) which supports v2 source.

emgarten · 2016-03-10T20:56:39Z

@NN--- would you be able to try this using NuGet in Visual Studio with the same proget server and let me know if it works there?

https://dist.nuget.org/visualstudio-2015-vsix/v3.4.0-rc/NuGet.Tools.vsix

There have been some changes in the V2 protocol and it would help to know if this is a problem in the install command, or if NuGet has a general problem with proget servers and non-normalized package versions.

NN--- · 2016-03-10T20:58:44Z

Both don't work.
I suspected VS extension and check also the command line tool.

ProGet server can be downloaded and installed for free if you want to check it directly.

zhili1208 · 2016-03-10T21:39:51Z

I didn't repro this with ProGet on my machine, so can you specify -Verbosity in command Line, then you can see all http call. try the http call, I guess it returns invalid xml.

emgarten · 2016-03-10T21:58:10Z

nuget install A -version 1.1.1.0 --verbosity detailed

NN--- · 2016-03-11T11:22:59Z

This what I get with nuget 3.4 RC:

System.AggregateException: One or more errors occurred. ---> System.InvalidOperationException: An error occurred while retrieving package metadata for 'A.1.1.1' from source 'ProGet'. ---> NuGet.Protocol.Core.Types.FatalProtocolException: An error occurred while retrieving package metadata for 'A.1.1.1' from source 'ProGet'. ---> System.Xml.XmlException: Data at the root level is invalid. Line 1, position 1.
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.Throw(String res, String arg)
   at System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace()
   at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
   at System.Xml.XmlTextReaderImpl.Read()
   at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
   at NuGet.Protocol.V2FeedParser.LoadXml(Stream stream)
   at NuGet.Protocol.V2FeedParser.<QueryV2Feed>d__49.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Protocol.V2FeedParser.<GetPackage>d__40.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Protocol.DependencyInfoResourceV2Feed.<ResolvePackage>d__4.MoveNext()
   --- End of inner exception stack trace ---
   at NuGet.Protocol.DependencyInfoResourceV2Feed.<ResolvePackage>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.ResolverGather.<GatherPackageFromSourceAsync>d__27.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at NuGet.PackageManagement.ResolverGather.<GatherPackageAsync>d__26.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.ResolverGather.<>c__DisplayClass25_0.<<StartWorkerTasks>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.ResolverGather.<ProcessResultsAsync>d__24.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.ResolverGather.<StartTasksAndProcessWork>d__21.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at NuGet.PackageManagement.ResolverGather.<GatherAsync>d__20.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.ResolverGather.<GatherAsync>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at NuGet.PackageManagement.NuGetPackageManager.<PreviewInstallPackageAsync>d__43.MoveNext()
   --- End of inner exception stack trace ---
   at NuGet.PackageManagement.NuGetPackageManager.<PreviewInstallPackageAsync>d__43.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.NuGetPackageManager.<InstallPackageAsync>d__28.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at NuGet.CommandLine.InstallCommand.<InstallPackage>d__34.MoveNext()
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at NuGet.CommandLine.Command.Execute()
   at NuGet.CommandLine.Program.MainCore(String workingDirectory, String[] args)
---> (Inner Exception #0) System.InvalidOperationException: An error occurred while retrieving package metadata for 'A.1.1.1' from source 'ProGet'. ---> NuGet.Protocol.Core.Types.FatalProtocolException: An error occurred while retrieving package metadata for 'A.1.1.1' from source 'ProGet'. ---> System.Xml.XmlException: Data at the root level is invalid. Line 1, position 1.
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.Throw(String res, String arg)
   at System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace()
   at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
   at System.Xml.XmlTextReaderImpl.Read()
   at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
   at NuGet.Protocol.V2FeedParser.LoadXml(Stream stream)
   at NuGet.Protocol.V2FeedParser.<QueryV2Feed>d__49.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Protocol.V2FeedParser.<GetPackage>d__40.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Protocol.DependencyInfoResourceV2Feed.<ResolvePackage>d__4.MoveNext()
   --- End of inner exception stack trace ---
   at NuGet.Protocol.DependencyInfoResourceV2Feed.<ResolvePackage>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.ResolverGather.<GatherPackageFromSourceAsync>d__27.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at NuGet.PackageManagement.ResolverGather.<GatherPackageAsync>d__26.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.ResolverGather.<>c__DisplayClass25_0.<<StartWorkerTasks>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.ResolverGather.<ProcessResultsAsync>d__24.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.ResolverGather.<StartTasksAndProcessWork>d__21.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at NuGet.PackageManagement.ResolverGather.<GatherAsync>d__20.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.ResolverGather.<GatherAsync>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at NuGet.PackageManagement.NuGetPackageManager.<PreviewInstallPackageAsync>d__43.MoveNext()
   --- End of inner exception stack trace ---
   at NuGet.PackageManagement.NuGetPackageManager.<PreviewInstallPackageAsync>d__43.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.NuGetPackageManager.<InstallPackageAsync>d__28.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at NuGet.CommandLine.InstallCommand.<InstallPackage>d__34.MoveNext()<---

This what I have with 3.3:

Feeds used:
  http://ProGet/nuget/Default

Attempting to gather dependencies information for package 'A.1.1.1' with respect to project 'C:\Users\test\Downloads', targeting 'Any,Version=v0.0'
Attempting to resolve dependencies for package 'A.1.1.1' with DependencyBehavior 'Lowest'
Resolving actions to install package 'A.1.1.1'
Resolved actions to install package 'A.1.1.1'
Adding package 'A.1.1.1' to folder 'C:\Users\test\Downloads'
Added package 'A.1.1.1' to folder 'C:\Users\test\Downloads'
Successfully installed 'A 1.1.1' to C:\Users\test\Downloads

NN--- · 2016-03-11T11:25:59Z

This is HTTP request of 3.4:

GET /nuget/Default/Packages(Id='A',Version='1.1.1') HTTP/1.1

And this is of 3.3

GET /nuget/Default/Packages(Id='A',Version='1.1.1.0') HTTP/1.1

ProGet differs 1.1.1 from 1.1.1.0 that's why it doesn't work with NuGet 3.4.

yishaigalatzer · 2016-03-11T21:24:16Z

That looks like a bug in ProGet, the ID is identical. I don't want to fix this in NuGet this late close to the release of 3.4, either fix the packages or contact ProGet to update their API

NN--- · 2016-03-11T22:52:03Z

If it is bug in ProGet then It is a bug in all older NuGet versions.
This change makes a regression.
Supposing I had a package 1.1.1.0 , after installing it, it added using ".targets" file in my project with path packages\A-1.1.1.0.
With 3.4 I get a folder packages\A-1.1.1 and my code won't compile.

In case this will be a default behavior with no regrets , please document it as a breaking change since now you cannot install a package which you could.
Also it means that all tools (like CoApp) must be updated to always normalize version.

yishaigalatzer · 2016-03-11T22:54:38Z

If it is bug in ProGet then It is a bug in all older NuGet versions.

The bug is that the server doesn't respect normalized versions, nuget is making an API call with a normalized version.

With 3.4 I get a folder packages\A-1.1.1 and my code won't compile.

I'm not aware of such an issue, that is a breaking change and we will fix it in 3.3.

NN--- · 2016-03-11T22:58:17Z

I see what you mean.
Tell me if I have package versions 1.1.1.0 should it be installed to A-1.1.1.0. folder or A-1.1.1 ?
Or perhaps it depends what version I specify to I install it?

apxltd · 2016-03-11T23:01:36Z

I just checked w/ the team here.

We had to specifically implement the “4th part quirk” because NuGet (as of 3.3 and earlier treated) considers these as different versions. A significant number of packages and users relied on this behavior (and we received a lot of complaints about this) which is why we specifically added it.

Note that NuGet 3.3 and earlier also has the “leading zeros quirk” (for example, 1.01.0 ?= 1.1.0, depending on the query), but we chose not to implement that because only handful of packages (including, I think Ninject or Rhino or something?) used leading zeros to differentiate packages.

We agree in principle that "1.1.1 == 1.1.1.0" are identical. But since NuGet 3.3 and earlier (as well as lots of users) disagree, our principle didn't really matter here... however we did stick to our principle that "1.1.1 == 1.01.1". ProGet does not support that, where asNuGet does.

To be honest we really didn't want to have to implement the "4th part quirk", and would greatly prefer using semantic versioning (like we do with other package formats), but it's been there since NuGet 1.x, and people use and rely on it. I agree with @nn that this is a breaking change and should be documented as such. It's kind of a big one.

We've been getting quite a few complaints about this one already from 3.4-RC users, so it's gonna be a bit of a pain for them, because all we can tell them is "don't upgrade or don't rely on that behavior".

yishaigalatzer · 2016-03-11T23:19:26Z

Hey Alex, I guess the ask is to respect the query but return the metadata as is in the nuspec, that wouldnt be a breaking change.

Will double check on our side.

apxltd · 2016-03-12T16:42:24Z

I'm not sure I understand? NuGet 3.3 and earlier already supports A-1.1.0 and A-1.1.0.0 in the same feed. So, they are currently considered different packages.

I think the existing behavior is strange... but seems like it'd be even stranger to specify:

1.1.0 is returned if you ask for 1.1.0.0, unless there is already a 1.1.0.0 package
1.1.0.0 is returned if you ask for 1.1.0, unless there is already a 1.1.0 package
PACKAGE_NOT_FOUND is returned if you ask for 1.0, even if there is 1.0.0

And then this will be even stranger when you consider "connectors" that aggregate multiple feeds. Which basically, everyone in a environment uses.

We really can't drop support for the "4th part quirk" in ProGet anytime soon, because many people are still on NuGet 2.x and rely on this behavior. At best, we could do a hack like "enable 4th part quirk mode" on a feed.

If you make this change, then it's a breaking API change. NuGet users are used to that. But please please please strongly document it in the release notes as a breaking change, so we can at least point the onslaught of users to that instead and advise them not to upgrade or not to rely on the behavior.

yishaigalatzer · 2016-03-12T17:05:02Z

That's not what we are saying:

1.1 is the same as 1.1.0 in terms of version equality, you cannot and should not have both of them on the same feed. Never

However when you restore a package nuget2 uses the nuspec ID to put it in the solution packages folder. Nuget 3 does the same, but normalizes it in the global packages folder.

There is no change here other than allowing a search/download request to find the package based on the normalized version. You still need to return the original ID from the nuspec.

If you still have concerns let's get on Skype/phone and hash because we are locking down the rtm release and id like to address this if I'm in the wrong

NN--- · 2016-03-13T17:52:25Z

@yishaigalatzer That is reasonable for me. I don't have duplicates.
Actually the version with 4th zero was an accident and wasn't intended at all.
But anyhow it helped to find a breaking change.

apxltd · 2016-03-14T00:35:47Z

So in summary I think we want to declare this a breaking change even if slight for most folks and call it a day. Nuget needs to move off the crippling legacy modes from 4 years ago.

👍 -- we'll see how many folks notice, and enforce it on the ProGet end at some point (maybe as an option, maybe not). I think it's easy enough simply not to upgrade if it's that big of a deal.

NN--- · 2016-03-14T19:28:59Z

@apapadimoulis Will it be possible given package 1.1.0.0 to ask for 1.1 and get the package successfully ?

apxltd · 2016-03-14T20:01:00Z

@NN--- I'm afraid not, because then that would be a breaking change on the server side, as 3.4 and pre-3.4 resolution logic is incompatible.

So for now, I would suggest to simply not upgrade to 3.4 if you rely on pre-3.4 logic.

NN--- · 2016-03-14T20:05:25Z

It is not a problem for me to add the same package of 1.1.1.0 with version 1.1.1 and have both in the server.
That way both pre-3.4 and 3.4 will work.

I don't know how many people have really different packages with trailing zeros.
My guess that most just didn't bother with normalizing like me since it just worked.

yishaigalatzer · 2016-03-14T20:06:52Z

@apapadimoulis that is not a major breaking change, and you should absolutely support it. Duplicate packages of the same version is a non-scenario.

apxltd · 2016-03-14T20:54:54Z

@yishaigalatzer I'd thought so too... except there were a lot of folks that had A-1, A1.0, A-1.0.0, etc. in their feed, so we had to implement it to allow them to migrate or use connectors to existing feeds...

But I agree, they probably aren't relying on "1.0.0" returning PACKAGE_NOT_FOUND if there is a "1.0.0.0" in the feed. So, we could ship that as a 3.4-compatiability maintenance version if needed.

So just to make sure I understand the specs...

The 3.4 client will always send a "normalized version" in the query.
A "normalized version" has 4 parts (0.0.0.0)
If a non-normalized version" has less than 4 parts, you can normalize it by appending .0's to it

yishaigalatzer · 2016-03-14T21:15:44Z

Short term, we plan to improve the 3.4 behavior as follows - And we will put bits in your hands as soon as they are ready (on the myget nugetbuild feed).

3.4 client will send a normalized version first which is 3 digits or 4 as applicable.
For example:

User input	Id in nuspec	Request	Response
1.0	1.0.0.0	1.0.0	Value in nuspec
1.00	1.0	1.0.0	Value in nuspec
1.00.0.1	1.0.0.1	1.0.0.1	Value in nuspec

Also we identified that the root issue in the proget repo is that it returns a 200/html instead of 404 for that request. So lets get that fixed as well.

If we get a 404 we will get all versions of the packages and pick it from there (this is already in the code but failed because of the 200/html response)

joelverhagen · 2016-03-16T02:46:06Z

@zhili1208 we need to get this back into 3.4 RTM and get it fixed, it will be too big of a breaking change to handle.

We are now observing HTTP status codes correctly for V2 feeds with NuGet/NuGet.Client#374.

maartenba · 2016-03-16T10:11:51Z

NuGet.Server now also supports normalized versions.

joelverhagen · 2016-03-16T22:17:24Z

I applied the fix, as mentioned above and @zhili1208 validated this on NuGet.org, ProGet, and NuGet.Server.

fahadash · 2016-08-18T23:02:48Z

Is this fix up on the VS Extensions and Updates manager? I looked for updates on Nuget Package Manager and found nothing.

yishaigalatzer · 2016-08-18T23:49:41Z

@fahadash Yes, what version do you have installed?

fahadash · 2016-08-19T14:02:24Z

@yishaigalatzer I have 3.4.4.1321 . I installed VS 2015 Update 2 and it works fine now. Thanks.

emgarten assigned zhili1208 Mar 10, 2016

emgarten added Priority:1 High priority issues that must be resolved in the current sprint. Product:VS.Client Type:Bug labels Mar 10, 2016

emgarten added this to the 3.4 RTM milestone Mar 10, 2016

yishaigalatzer modified the milestones: 3.4 RTM, 3.4 RTM - Triage Mar 11, 2016

yishaigalatzer modified the milestones: 3.5 Beta, 3.4 RTM - Triage Mar 11, 2016

yishaigalatzer added Product:NuGet.exe NuGet.exe and removed Priority:1 High priority issues that must be resolved in the current sprint. labels Mar 11, 2016

yishaigalatzer mentioned this issue Mar 12, 2016

Nuget restore and install fails to install packages with versions that are not normalized #2307

Closed

yishaigalatzer added the ShipRoom Check label Mar 14, 2016

zhili1208 added a commit to NuGet/NuGet.Client that referenced this issue Mar 14, 2016

fixed NuGet/Home#2298

90f92e3

zhili1208 mentioned this issue Mar 14, 2016

fixed https://github.com/NuGet/Home/issues/2298 NuGet/NuGet.Client#367

Closed

yishaigalatzer added ShipRoom Approved and removed ShipRoom Check labels Mar 15, 2016

csharpfritz mentioned this issue Mar 15, 2016

Added normalized version number section NuGet/NuGetDocs#444

Merged

maartenba mentioned this issue Mar 15, 2016

NuGet.Server - Support normalized version (and use it in queries) NuGet/NuGetGallery#2944

Closed

joelverhagen mentioned this issue Mar 16, 2016

Observer status code in V2FeedParser NuGet/NuGet.Client#374

Merged

yishaigalatzer assigned joelverhagen and unassigned zhili1208 Mar 16, 2016

joelverhagen closed this as completed Mar 16, 2016

MarkusWild mentioned this issue Aug 15, 2016

VS Nuget Client 3.3 resolves Dependencies - VS Nuget Client 3.4.4 does not #3311

Closed

dmeyer573 mentioned this issue Sep 21, 2016

NuGet v3.4 not requesting full version on restore when normalized version results in 404 #3492

Closed

rrelyea mentioned this issue Dec 10, 2016

Package restore does not correctly restore packages with a version of x.0.0.0 #4081

Closed

apxltd mentioned this issue Aug 9, 2017

Question about Normalized Version Numbers and third party Nuget server (ProGet) fsprojects/Paket#1777

Open

apxltd mentioned this issue Aug 30, 2017

Allow for package release notation chocolatey/nuget-chocolatey#11

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

NuGet 3.4 fails to install package ending with zero #2298

NuGet 3.4 fails to install package ending with zero #2298

NN--- commented Mar 10, 2016

emgarten commented Mar 10, 2016

NN--- commented Mar 10, 2016

emgarten commented Mar 10, 2016

NN--- commented Mar 10, 2016

zhili1208 commented Mar 10, 2016

emgarten commented Mar 10, 2016

NN--- commented Mar 11, 2016

NN--- commented Mar 11, 2016

yishaigalatzer commented Mar 11, 2016

NN--- commented Mar 11, 2016

yishaigalatzer commented Mar 11, 2016

NN--- commented Mar 11, 2016

apxltd commented Mar 11, 2016

yishaigalatzer commented Mar 11, 2016

apxltd commented Mar 12, 2016

yishaigalatzer commented Mar 12, 2016

NN--- commented Mar 13, 2016

apxltd commented Mar 14, 2016

NN--- commented Mar 14, 2016

apxltd commented Mar 14, 2016

NN--- commented Mar 14, 2016

yishaigalatzer commented Mar 14, 2016

apxltd commented Mar 14, 2016

yishaigalatzer commented Mar 14, 2016

joelverhagen commented Mar 16, 2016

maartenba commented Mar 16, 2016

joelverhagen commented Mar 16, 2016

fahadash commented Aug 18, 2016

yishaigalatzer commented Aug 18, 2016

fahadash commented Aug 19, 2016

NuGet 3.4 fails to install package ending with zero #2298

NuGet 3.4 fails to install package ending with zero #2298

Comments

NN--- commented Mar 10, 2016

emgarten commented Mar 10, 2016

NN--- commented Mar 10, 2016

emgarten commented Mar 10, 2016

NN--- commented Mar 10, 2016

zhili1208 commented Mar 10, 2016

emgarten commented Mar 10, 2016

NN--- commented Mar 11, 2016

NN--- commented Mar 11, 2016

yishaigalatzer commented Mar 11, 2016

NN--- commented Mar 11, 2016

yishaigalatzer commented Mar 11, 2016

NN--- commented Mar 11, 2016

apxltd commented Mar 11, 2016

yishaigalatzer commented Mar 11, 2016

apxltd commented Mar 12, 2016

yishaigalatzer commented Mar 12, 2016

NN--- commented Mar 13, 2016

apxltd commented Mar 14, 2016

NN--- commented Mar 14, 2016

apxltd commented Mar 14, 2016

NN--- commented Mar 14, 2016

yishaigalatzer commented Mar 14, 2016

apxltd commented Mar 14, 2016

yishaigalatzer commented Mar 14, 2016

joelverhagen commented Mar 16, 2016

maartenba commented Mar 16, 2016

joelverhagen commented Mar 16, 2016

fahadash commented Aug 18, 2016

yishaigalatzer commented Aug 18, 2016

fahadash commented Aug 19, 2016