In .xproj project.json, make sure a package is uninstalled before installing #823
Conversation
|
|
||
| if (packageToReplace != null) | ||
| { | ||
| await UninstallPackageAsync(packageToReplace.PackageIdentity, nuGetProjectContext, token); |
There was a problem hiding this comment.
what function is called into when we update from updates tab?
is there a way we can make the codepath for update from update tab same as the update from any other place? this would ensure we don't have to change behavior in different places in the future...
There was a problem hiding this comment.
This is a possibility, but given that this ProjkectKNuGetProject (.xproj) implementation is going away soon, I opted to not refactor the other two NuGet project types for a problem specific to .xproj.
There was a problem hiding this comment.
I Assume that this UninstallPackage would keep state key that you send to InstallPackage below via args? If yes then lgtm.
There was a problem hiding this comment.
Correct. The UninstallPackageAsync is the exact same method that is invoked when during a batch update or an explicit uninstall.
|
LGTM otherwise. |
|
|
1 similar comment
|
|
joelverhagen
force-pushed
the
jver-3303
branch
from
00eeaef
to
31da2ab
Compare
This is for NuGet/Home#3303.
When updating a package in a .xproj project.json we want to maintain state in that dependency node. For example, if a dependency has
"target": "project", this should not be lost during an update of that dependency. This works today when using the Updates tab in the VS UI or when usingUpdate-PackagePMC command. However, when pressing the Update button under the Installed or Browse tabs, this state is lost. The root cause of this is that the user's update action only registers as an "install" operation. When usingUpdate-Package, both an "uninstall" and "install" occur.This is only a problem for .xproj project.json because UWP project.json merges an install of an already installed package into the existing project.json.
The fix is to uninstall before installing. This will then allow the update state to be populated and used on the subsequent install.
One problem I noticed while testing this that the Browse and Updates tabs don't always have the result of an install/update immediately visible. In other words, the user presses install/update, NuGet executes the install/update, then the UI refreshes, showing the state prior to the install/update. This is because the project.json restores happen asynchronously. Since this is a pre-existing issue with install, I decided not to address it.
/cc @emgarten @rohit21agrawal @alpaix @abpiskunov