New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
stevenscreek opened this Issue Jul 25, 2015 · 3 comments

Comments

Projects
None yet
6 participants
@stevenscreek

stevenscreek commented Jul 25, 2015

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.

@emgarten emgarten added this to the 3.2.0-Beta milestone Jul 27, 2015

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Oct 27, 2015

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

CC @emgarten

yishaigalatzer commented Oct 27, 2015

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

CC @emgarten

@johnataylor

This comment has been minimized.

Show comment
Hide comment
@johnataylor

johnataylor Nov 2, 2015

Member

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.

Member

johnataylor commented Nov 2, 2015

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.

@johnataylor johnataylor modified the milestones: 3.4, 3.3.0-Beta Nov 2, 2015

@johnataylor johnataylor assigned RanjiniM and unassigned johnataylor Nov 13, 2015

@yishaigalatzer yishaigalatzer modified the milestones: 3.4 Beta, 3.4 RTM Feb 25, 2016

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

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

@yishaigalatzer yishaigalatzer modified the milestones: 3.5 Beta, 3.5 RC Apr 8, 2016

@jainaashish

This comment has been minimized.

Show comment
Hide comment
@jainaashish

jainaashish Apr 29, 2016

Contributor

6327234c4dafc32c6d50817680725f23906aae03

Contributor

jainaashish commented Apr 29, 2016

6327234c4dafc32c6d50817680725f23906aae03

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment