update-package in v3 fails with packages not in the specified source

[stevenscreek]

The update-package powershell command in v3 fails when a package is not available in the specified source. This is a regression from v2.

v3:

PM> update-package -whatif -projectname OurProject -source http://our-build-ci-nuget-server/
Attempting to gather dependencies information for multiple packages with respect to project 'OurProject', targeting '.NETFramework,Version=v4.5'
update-package : Package 'Microsoft.AspNet.WebApi.Client' is not found
At line:1 char:1

• update-package -whatif -projectname OurProject -source http://our-build-ci...

• - CategoryInfo          : NotSpecified: (:) [Update-Package], Exception
  - FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.UpdatePackageCommand
  
  

v2:

PM> update-package -whatif -projectname OurProject -source http://our-build-ci-nuget-server/
No updates available for 'Microsoft.AspNet.WebApi.Client'.
No updates available for 'Newtonsoft.Json'.
No updates available for 'Microsoft.Net.Http'.
Updating 'OurPackage' from version '1.1300.14' to '1.1300.18' in project 'OurProject'.

We keep external dependencies on a separate nuget server than items produced by our build pipeline. This way we can upgrade just the internal dependencies.

[yishaigalatzer]

@johnataylor can you assess the state of this bug after the last round of changes you made to update-package ?

CC @emgarten

[johnataylor]

I just confirmed that this is definitely a bug. The problem is that the code in ResolverGather expects every primary id to be present in the primary sources. This is the wrong semantic for Update ALL and essentially a regression from v2.

The offending code is https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.PackageManagement/Resolution/ResolverGather.cs#L202

In an Update ALL scenario we don't want this exception thrown. That suggests we have a layering problem here too. The decision to throw the exception should come from the code in NuGetPackageManager.cs as it is the code that understands the scenarios.

Unfortunately its too late to fix this for the 3.3 release. But this should be a priority for 3.4.

In the meantime the workaround is to use the Update-Package command with a specific -Id flag.

[jainaashish]

6327234