In the example below it reinstalled and older version of a dependency (jQuery).
Id Version
-- -------
EntityFramework 4.1.10331.0
jQuery 1.5.1
jQuery.UI.Combined 1.8.11
jQuery.Validation 1.8.0
jQuery.vsdoc 1.5.1
Modernizr 1.7
PM> update-package jquery.Validation -reinstall
Successfully removed 'jQuery.Validation 1.8.0' from MvcApplication34.
Successfully removed 'jQuery 1.5.1' from MvcApplication34.
Successfully uninstalled 'jQuery.Validation 1.8.0'.
Successfully uninstalled 'jQuery 1.5.1'.
Attempting to resolve dependency 'jQuery (≥ 1.3.2 && ≤ 1.6)'.
Successfully installed 'jQuery 1.4.4'.
Successfully installed 'jQuery.Validation 1.8'.
Successfully added 'jQuery 1.4.4' to MvcApplication34.
Successfully added 'jQuery.Validation 1.8' to MvcApplication34.
PM> get-package
Id Version
-- -------
EntityFramework 4.1.10331.0
jQuery 1.4.4
jQuery.UI.Combined 1.8.11
jQuery.Validation 1.8
jQuery.vsdoc 1.5.1
Modernizr 1.7
Comments: This has come up a handful more times and it's confusing for sure. The problem is that the aforementioned 2 scenarios conflict each other. We cannot distinguish between a reinstall attempting to reinstall the current version of all packages and a reinstall attempting to get back to the last-known-good state. Presently, we go back to what we think is the last known good state, but here's my assessment of that: * It's merely an attempt * It's not known to really be a last known good state * For getting back to last known good (say a package update broke you), you should just rely on source control for that * There are mainline scenarios (like framework retargeting) where I need to reinstall the current version, and that is hard to do right now With this, I propose that we reverse our stance on what a reinstall means, and change the implementation such that it will reinstall the current versions of your packages. Where the design gets a bit messy though is when your target framework changed and that changes which dependencies you need, then we might need more (or fewer) packages. I suggest that we will pull in new dependencies, but we won't cull any seemingly unneeded ones (since we cannot determine if the project has a direct need for the package or if it was only there to satisfy a dependency).
Id Version
-- -------
EntityFramework 4.1.10331.0
jQuery 1.5.1
jQuery.UI.Combined 1.8.11
jQuery.Validation 1.8.0
jQuery.vsdoc 1.5.1
Modernizr 1.7
PM> update-package jquery.Validation -reinstall
Successfully removed 'jQuery.Validation 1.8.0' from MvcApplication34.
Successfully removed 'jQuery 1.5.1' from MvcApplication34.
Successfully uninstalled 'jQuery.Validation 1.8.0'.
Successfully uninstalled 'jQuery 1.5.1'.
Attempting to resolve dependency 'jQuery (≥ 1.3.2 && ≤ 1.6)'.
Successfully installed 'jQuery 1.4.4'.
Successfully installed 'jQuery.Validation 1.8'.
Successfully added 'jQuery 1.4.4' to MvcApplication34.
Successfully added 'jQuery.Validation 1.8' to MvcApplication34.
PM> get-package
Id Version
-- -------
EntityFramework 4.1.10331.0
jQuery 1.4.4
jQuery.UI.Combined 1.8.11
jQuery.Validation 1.8
jQuery.vsdoc 1.5.1
Modernizr 1.7
Comments: This has come up a handful more times and it's confusing for sure. The problem is that the aforementioned 2 scenarios conflict each other. We cannot distinguish between a reinstall attempting to reinstall the current version of all packages and a reinstall attempting to get back to the last-known-good state. Presently, we go back to what we think is the last known good state, but here's my assessment of that: * It's merely an attempt * It's not known to really be a last known good state * For getting back to last known good (say a package update broke you), you should just rely on source control for that * There are mainline scenarios (like framework retargeting) where I need to reinstall the current version, and that is hard to do right now With this, I propose that we reverse our stance on what a reinstall means, and change the implementation such that it will reinstall the current versions of your packages. Where the design gets a bit messy though is when your target framework changed and that changes which dependencies you need, then we might need more (or fewer) packages. I suggest that we will pull in new dependencies, but we won't cull any seemingly unneeded ones (since we cannot determine if the project has a direct need for the package or if it was only there to satisfy a dependency).