dotnet restore with multiple sources crashes

From @citizenmatt on August 29, 2017 16:34

Details about Problem

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe): dotnet.exe

NuGet version (x.x.x.xxx): 3.4.3.855

dotnet.exe --version (if appropriate): 2.0.0

OS version (i.e. win10 v1607 (14393.321)): win10 v1703 (16275.1000)

Worked before? If so, with which NuGet version: dotnet.exe 1.x

Detailed repro steps so we can see the same problem

1. dotnet new console
2. dotnet restore --source foo --source https://foo

Results in output:

C:\Program Files\dotnet\sdk\2.0.0\NuGet.targets(466,5): error : The given path's format is not supported. [C:\foo\foo.csproj]

However, dotnet restore --source https://foo --source foo works correctly.

I think the two sources are passed through as a string such as foo;https://foo, rather than as two values in a string array. Passing this string to Path.GetFullPath causes the same error. Modifying NuGet.targets to pass in an ItemGroup containing the same two values works correctly (well, fails since I’m using silly values).

Other suggested things

Verbose Logs

Snipped from dotnet restore --source foo --source https://foo -v d:

       Using "GetRestoreSettingsTask" task from assembly "C:\Program Files\dotnet\sdk\2.0.0\NuGet.Build.Tasks.dll".
       Task "GetRestoreSettingsTask"
         (in) ProjectUniqueName 'C:\foo\foo.csproj'
         (in) RestoreSources 'foo;https://foo'
         (in) RestorePackagesPath ''
         (in) RestoreFallbackFolders ''
         (in) RestoreConfigFile ''
         (in) RestoreSolutionDirectory ''
         (in) RestorePackagesPathOverride ''
         (in) RestoreSourcesOverride 'foo;foo'
         (in) RestoreFallbackFoldersOverride ''
   1:6>C:\Program Files\dotnet\sdk\2.0.0\NuGet.targets(466,5): error : The given path's format is not supported. [C:\foo\foo.csproj]
         System.NotSupportedException: The given path's format is not supported.
            at System.IO.Path.GetFullPath(String path)
            at NuGet.Common.UriUtility.GetAbsolutePath(String rootDirectory, String path)
            at NuGet.Build.Tasks.GetRestoreSettingsTask.<Execute>b__61_4(String e)
            at System.Linq.Utilities.<>c__DisplayClass2_0`3.<CombineSelectors>b__0(TSource x)
            at System.Linq.Enumerable.SelectArrayIterator`2.ToArray()
            at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
            at NuGet.Build.Tasks.GetRestoreSettingsTask.<Execute>b__61_3()
            at NuGet.Build.Tasks.RestoreSettingsUtils.GetValue[T](Func`1[] funcs)
            at NuGet.Build.Tasks.GetRestoreSettingsTask.Execute()
       Done executing task "GetRestoreSettingsTask" -- FAILED.
   1:6>Done building target "_GetRestoreSettings" in project "foo.csproj" -- FAILED.
 

Copied from original issue: NuGet/Home#5817

[livarcocc]

@emgarten we need your help here. You are asking us to undo your change without knowing why you put it in place to begin with.

[PulsarFX]

Is there any progress on this? I find multiple reports on this behaviour on stackoverflow and elsewhere, but no solution for it. For now only a workaround seems to exist, which is moving the http-source before the local source. This is crazy when only a few external packages are required, but lots of local packages. Doesn’t nuget try to find the package in the order the sources are given?

works:

"C:/Program Files/dotnet/dotnet.exe" restore "./src/Ng.Core/Ng.Core.sln" --source "https://nuget.devexpress..." --source "D:/vsts02/_work/2/s/nugetPackages" --no-cache

fails: "C:/Program Files/dotnet/dotnet.exe" restore "./src/Ng.Core/Ng.Core.sln" --source "D:/vsts02/_work/2/s/nugetPackages" --source "https://nuget.devexpress..." --no-cache with error:

error : Die lokale Quelle "D:\vsts02\_work\2\s\src\Ng.Core\https:\nuget.devexpress...." ist nicht vorhanden. 

It’s obvious that the http source is appended to the local path which will never work.

Root = D:\vsts02\_work\2\s