Home: PackageReference projects cannot find SemVer 2.0.0 packages

[joelverhagen]

It looks there are two FindPackagesById code paths:

Incorrect:
https://github.com/NuGet/NuGet.Client/blob/9f5c5b0a93eff691e3300605418b620f6c7991fc/src/NuGet.Core/NuGet.Protocol/RemoteRepositories/RemoteV2FindPackageByIdResource.cs#L345

Correct:
https://github.com/NuGet/NuGet.Client/blob/9f5c5b0a93eff691e3300605418b620f6c7991fc/src/NuGet.Core/NuGet.Protocol/LegacyFeed/V2FeedQueryBuilder.cs#L36

packages.config projects don't seem to be effected.

Tested dev branch, 4.3.0, 4.5.1. All have the same issue. I think we shipped SemVer 2.0.0 protocol support with this bug.

[joelverhagen]

This was discovered via a customer report on NuGet.Server: https://github.com/NuGet/NuGetGallery/issues/5528

They found it using latest .NET CLI.

[nwoolls]

Just tried this with 2.1 preview 1 and still see the issue there FYI.

[rrelyea]

Yes, we plan to fix this for vs2017 15.7/netcore 2.1.
If @joelverhagen cannot afford to do it this week or next week, we'll try to do it in our third week (bug fixing/stabilization) of this sprint.

[joelverhagen]

@rrelyea, PR is out. Minimal fix. We should do some refactoring in this area to reduce the chance of this kind of thing happening again... there are basically two implementations of calling FindPackagesById(). I made them share the URL building part.

[rducom]

Hi @rrelyea & @joelverhagen , I'm currently blocked by this issue, and there's no way to access CI build artefacts on the repository. I tried to build locally with build.ps1, without success.
Is there any way to get a patched NuGet.Tools.vsix as hotfix ?

[DoCode]

DotNet restore have the same behavior!
What's the state here?
No infos. No one who use SemVer v2 packages? Mhmm...

[gabrielhall2112]

I just found this thread, I'm having what seems to be the exact same issue:

I upgraded my organization's hosted Nuget Server, our nuget CLI tools and updated visual studio in hopes of using SemVer v2. I was able to push both stable releases ( _e.g. 1.0.0_, backwards compatible with SemVer v1) and prereleases ( _e.g. 1.0.0-alpha.1_, using new SemVer v2).

HOWEVER, in Visual Studio when attempting to install the pre-releases they are visible but won't install with an error of "1.0.0-alpha.1 was not found. An approximate best match of 1.0.0 was resolved." It installs the next closest version which is the stable releases that Visual Studio can find.

[DoCode]

@skarletlightning yes. We here 😉 know this since month...
No one from VS, DotNet and NuGet team priorized this issue 👆!
I think we are the only one with SemVer v2 packages 🤔

[rrelyea]

I commented on March 1st with: "Yes, we plan to fix this for vs2017 15.7/netcore 2.1."

@joelverhagen did the work to get it in, and it will be in 15.7 preview 3 -- which should ship any day now.

VS, msbuild and dotnet.exe scenarios that ship with that preview should be fixed.
NuGet.exe 4.7-preview 3 should be available on http://nuget.org/downloads within a day or two of preview3 shipping.

The release notes on this page will be updated with preview3 information as soon as that build has shipped: https://www.visualstudio.com/vs/preview/

Please let us know how that works for you.

[rducom]

@rrelyea I was meaning, an hotfix for vs 15.6.5, not 15.7 preview...
We publish nuget from stable VS, we consume them from stable VS...
Nuget.exe-preview3 is not an option since nuget tooling in VS works without the nuget.exe

It's a real blocker on our side : FindPackagesById is called with &semVerLevel=2.0.0 from nuget list view, and without &semVerLevel=2.0.0 when installing. So N1101, package not found...

We just can"t build - at ALL

So, this time, it should be a - really - good idea to provide a hot fix for the last stable VS version.
At least as a download link in this thread...

[rrelyea]

15.6.5 has already shipped, sorry. Workaround would be to use nuget.exe 4.7p3 and disable restore in VS temporarily.

Given that, we'll discuss if there are other options to unblock you.

[rrelyea]

@PatoBeltran - please reply to this issue when 4.7p3 nuget.exe is available.

[joelverhagen]

I've verified this on VS 15.7.0 Preview 4, nuget.exe 4.7.0-preview4, and .NET SDK 2.1.300-preview2-008533.

[nwoolls]

@joelverhagen @rrelyea how do we get this fix in place on a non-Windows OS, outside of VS? I am still seeing the problem w/ e.g.:

dotnet --version
2.1.402
dotnet restore
...
/Users/jdoe/src/Example.csproj : error NU1102: Unable to find package ExampleLibrary with version (>= 1.2.0-rc.1)
/Users/jdoe/src/Example.csproj : error NU1102:   - Found 11 version(s) in example.org [ Nearest version: 1.1.1 ]
/Users/jdoe/src/Example.csproj : error NU1102:   - Found 1 version(s) in nuget.org [ Nearest version: 1.0.0 ]

The same works fine if the version is 1.2.0-rc1 instead of 1.2.0-rc.1.

[rrelyea]

@joelverhagen - can you please investigate in 2.1.400 and/or 2.1.500 (15.9 code base)?

[joelverhagen]

@nwoolls, I just tried on 2.1.402 (downloaded from here) and it worked fine for me.

2.1.300-preview2-008533-win-x64 was the first version I could find on the download archive site that works.

I was able to reproduce the problem by using 2.1.300-preview1-008174 and setting DOTNET_MULTILEVEL_LOOKUP environment variable to 0.

Could you restore using restore -f --no-cache -v d and find:

• What was the path to your NuGet.Build.Tasks.dll used during restore?
  
  
  
  • Mine was C:\Users\jver\Downloads\dotnet-sdk-2.1.300-preview2-008533-win-x64\sdk\2.1.300-preview2-008533\NuGet.Build.Tasks.dll.
  
  
• What was the version of the NuGet.Build.Tasks.dl?
  
  
  
  • Mine was 4.7.0.5065
  
  
• Was semVerLevel=2.0.0 in the HTTP request to your V2 server?
  
  
  
  • Yes, one of my URLs was http://localhost:47564/nuget/FindPackagesById()?id='SemVerTest'&semVerLevel=2.0.0.
  
  

This restore command ignores the restore no-op logic, skips HTTP cache, and enables detailed logging.

The end of the restore output has from "GET" and "OK" log lines that indicate whether the semVerLevel=2.0.0 query parameter was used as well as the version of NuGet that ran the restore.

Using "RestoreTask" task from assembly "C:\Users\jver\Downloads\dotnet-sdk-2.1.300-preview2-008533-win-x64\sdk\2.1.300-preview2-008533\NuGet.Build.Tasks.dll".
...
GET http://localhost:47564/nuget/FindPackagesById()?id='SemVerTest'&semVerLevel=2.0.0

If I look at the version of this NuGet.Build.Tasks.dll assembly I see that it is 4.7.0.5065.

The end of my log looked like this:

       Using "RestoreTask" task from assembly "C:\Users\jver\Downloads\dotnet-sdk-2.1.300-preview2-008533-win-x64\sdk\2.1.300-preview2-008533\NuGet.Build.Tasks.dll".
       Task "RestoreTask"
         (in) RestoreGraphItems Count '4'
         (in) RestoreDisableParallel 'False'
         (in) RestoreNoCache 'True'
         (in) RestoreIgnoreFailedSources 'False'
         (in) RestoreRecursive 'True'
         (in) RestoreForce 'True'
         (in) HideWarningsAndErrors 'False'
         Running restore with 8 concurrent jobs.
         Reading project file C:\Users\jver\Desktop\semver2\testproj\testproj.csproj.
         Restoring packages for C:\Users\jver\Desktop\semver2\testproj\testproj.csproj...
         Restoring packages for .NETFramework,Version=v4.6...
           GET http://localhost:47564/nuget/FindPackagesById()?id='SemVerTest'&semVerLevel=2.0.0
           OK http://localhost:47564/nuget/FindPackagesById()?id='SemVerTest'&semVerLevel=2.0.0 89ms
           GET http://localhost:47564/nuget/Packages(Id='SemVerTest',Version='1.0.1')/Download
           OK http://localhost:47564/nuget/Packages(Id='SemVerTest',Version='1.0.1')/Download 8ms
         Resolving conflicts for .NETFramework,Version=v4.6...
         Acquiring lock for the installation of SemVerTest 1.0.1
         Acquired lock for the installation of SemVerTest 1.0.1
         Installing SemVerTest 1.0.1.
         Completed installation of SemVerTest 1.0.1
         Scanning packages for runtime.json files...
         Restoring packages for .NETFramework,Version=v4.6/win7-x86...
         Resolving conflicts for .NETFramework,Version=v4.6/win7-x86...
         Checking compatibility of packages on .NETFramework,Version=v4.6.
         Checking compatibility for testproj 1.0.0 with .NETFramework,Version=v4.6.
         Checking compatibility for SemVerTest 1.0.1 with .NETFramework,Version=v4.6.
         All packages and projects are compatible with .NETFramework,Version=v4.6.
         Checking compatibility of packages on .NETFramework,Version=v4.6 (win7-x86).
         Checking compatibility for testproj 1.0.0 with .NETFramework,Version=v4.6 (win7-x86).
         Checking compatibility for SemVerTest 1.0.1 with .NETFramework,Version=v4.6 (win7-x86).
         All packages and projects are compatible with .NETFramework,Version=v4.6 (win7-x86).
         Committing restore...
         Writing lock file to disk. Path: C:\Users\jver\Desktop\semver2\testproj\obj\project.assets.json
         Writing cache file to disk. Path: C:\Users\jver\Desktop\semver2\testproj\obj\testproj.csproj.nuget.cache
         Restore completed in 461.12 ms for C:\Users\jver\Desktop\semver2\testproj\testproj.csproj.

         NuGet Config files used:
             C:\Users\jver\Desktop\semver2\NuGet.Config
             C:\Users\jver\AppData\Roaming\NuGet\NuGet.Config
             C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

         Feeds used:
             http://localhost:47564/nuget

         Installed:
             1 package(s) to C:\Users\jver\Desktop\semver2\testproj\testproj.csproj
       Done executing task "RestoreTask".

[joelverhagen]

Another thing, could you provide the output of dotnet --info?

[nwoolls]

@joelverhagen please note that this is all on Linux, not Windows.

What was the path to your NuGet.Build.Tasks.dll used during restore?

/usr/share/dotnet/sdk/2.1.402/NuGet.Build.Tasks.dll

What was the version of the NuGet.Build.Tasks.dl?

I don't know. I'd assume 2.1.402 from the file path, but I am unable to get the file version on Windows (the DLL properties show blank version info) or on Linux (using exiftool as shown here isn't reporting the version).

exiftool /usr/share/dotnet/sdk/2.1.402/NuGet.Build.Tasks.dll
ExifTool Version Number         : 9.46
File Name                       : NuGet.Build.Tasks.dll
Directory                       : /usr/share/dotnet/sdk/2.1.402
File Size                       : 110 kB
File Modification Date/Time     : 2018:08:30 23:51:34+00:00
File Access Date/Time           : 2018:10:18 17:42:25+00:00
File Inode Change Date/Time     : 2018:09:26 14:40:29+00:00
File Permissions                : rw-r--r--
Error                           : File format error

Was semVerLevel=2.0.0 in the HTTP request to your V2 server?

Yes, e.g.:

GET http://example.com/nuget/FindPackagesById()?id='MyPackage'&semVerLevel=2.0.0

Another thing, could you provide the output of dotnet --info?

> dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.1.402
 Commit:    3599f217f4

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  14.04
 OS Platform: Linux
 RID:         ubuntu.14.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.402/

Host (useful for support):
  Version: 2.1.4
  Commit:  85255dde3e

.NET Core SDKs installed:
  2.1.402 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

That being said, if I browse to http://example.com/nuget/FindPackagesById()?id='MyPackage'&semVerLevel=2.0.0 I do not see the SemVer 2.0.0 package that was published. Which is a bummer because that gets back to my original issue, which spawned this issue, reported here. In that cause, some 6 months ago, it seems like adding the semVerLevel query parm did the trick.

We are still on 2.14.2 of NuGet.Server. Please let me know how you'd like to proceed and on which issue / repo (this one looks closed).

[nwoolls]

@joelverhagen could it be that paging is causing the problem? Even though the initial request has the semVerLevel query parm, the URL in the link rel="next" href element at the end of the feed does not.

<link rel="next" href="http://example.com/nuget/FindPackagesById?id='MyPackage'&amp;$skiptoken='MyPackage','1.2.3-8-g6b82829'" />

Perhaps the first page will contain SemVer 2.0.0 versioned package, but not subsequent pages? That would also explain why the semVerLevel query parm worked in this issue as it was a dummy package and there were not multiple pages in the feed.

[joelverhagen]

Well, we have gone full circle haven't we?

It looks like there is also a server-side bug. In 2.14.2, I can confirm that I see no semVerLevel=2.0.0 query parameter on the next page URL. I tried 3.1.2 and it works just fine.. Could you switch to the 3.x train?

I have tracked the server-side problem here:
https://github.com/NuGet/NuGetGallery/issues/6585

[nwoolls]

@joelverhagen Thanks! Upgrading to 3.1.2 did the trick. The parm is now in the next-page URL and the .NET Core CLI tooling is working.

[Rajkumar-Uppala]

Hello there,
Currently i am using VS 2017 Version 15.9.3 and Nuget Package manager 4.6.0
Package Manager Console Host Version 4.9.0.5661

When i am trying to use the 'PackageReference' feature, I am experiencing an issue as below when trying to restore NuGet Packages.

Failed to retrieve information about 'cnLogger' from remote source 'http://londbcntfs/nuget/FindPackagesById()?id='cnLogger'&semVerLevel=2.0.0'.
Response status code does not indicate success: 404 (Not Found).

But if we restore them via old style (packages.config), we are able to retrieve them.

Please let me know if i can provide you any other details to validate this.

Could you please guide me, what might went wrong .

Thanks ,
Rajkumar.

[ScottyMacDev]

Hi,

I believe I am encountering the same situation in .NET Core 2.0 and 2.1 in Azure DevOps. In the csproj we have the version of a component as 1.0.0--version-- in the Package section as such:

Then we run a replace tokens on the csproj the RegEx --(\w+)-- and the version variable == -alpha

NuGet restore 2.x on Azure DevOps fails with this error:
error : '-alpha' is not a valid version string.

Any ideas for a workaround until the client in Azure DevOps is fixed? This is important to us because we have NuGet repository on MyGet and we use dev=alpha, qa=beta, uat=rc1 and prod=[blank] and follow SemVer 1.0 guidlines.

Thanks!