Updating All Packages
Issue: 431
There is currently no easy way to update all packages within a solution. In this iteration, we’ll update the Update-Package command to support updating all packages at the solution level and project level. We will not be adding support for this to the Add
Package Dialog in this iteration, but will consider it for a future iteration. We just need to think through the UI for that.
| Command |
Description |
Update-Package |
Updates all packages in all projects. |
Update-Package –Project ProjectName |
Updates all packages in the specified project |
Update-Package PackageId |
Breaking Change: Updates the specified package in all projects rather than just the current project |
Update-Package PackageKid –Project ProjectName |
No change: Updates the specified package in the specfied project only as before. |
Update-Package –Safe |
New –Safe flag only updates packages to the next “safe” version, which is the latest version with the same major and minor version number as the current package. |
-Safe Flag
By default, the update command upgrades packages to the latest version in the feed. The new –Safe flag allows for a more conservative upgrade option. When using the –Safe flag, packages are only upgraded to the
latest “build” (when describing a version as Major.Minor.Build.Revision).
In other words, if you have Elmah 1.0.0 installed, and 1.0.1, 1.0.2, and 1.1.0 are in the feed:
| Command |
Description |
Update-Package Elmah |
Updates Elmah to 1.1.0 |
Update-Package Elmah -Safe |
Updates Elmah to 1.0.2 |
Interesting cases
If you follow
our general guidance on dependency versioning and only specify minimum versions, updating all packages will update them all to the latest version. However in some cases where version ranges are used, not every package will be upgraded to the latest versions.
Let’s look at some interesting scenarios.
Dependencies On Min Versions
In the Feed:
Installed:
- SuperLogger 1.0
- Log4Net 1.0
This is a simple case. Running Update-Package will upgrade both packages to the latest version.
Result (Installed):
- SuperLogger 1.1
- Log4Net 1.2
Dependencies With Version Ranges
In the Feed:
Installed:
- SuperLogger 1.0
- Log4Net 1.0
In this case, SuperLogger 1.1 has a dependency with a version range. Thus Log4Net won’t be updated to the latest version because SuperLogger doesn’t support Log4Net 1.2.
Result (Installed):
- SuperLogger 1.1
- Log4Net 1.1
Dependencies With Some Version Range Conflicts
In the Feed:
-
SuperLogger 1.0, SuperLogger 1.1 (depend on log4net version 1.2 – 1.3 inclusive).
-
MyLogDisplayer 1.0 (depends on log4net 1.0 – 1.1 inclusive)
-
log4net 1.0, 1.1, 1.2, 1.3
Installed:
- SuperLogger 1.0
- MyLogDisplayer 1.0
- log4net 1.0
This is really just a variant of the previous case. In this case, SuperLogger cannot be upgraded because the new version requires at least log4net 1.2. But MyLogDisplayer won’t work with Log4Net 1.2. The only thing that gets upgraded is log4net to 1.1 because
1.1 is compatible with all the other dependent packages.
Result (Installed):
- SuperLogger 1.0
- MyLogDisplayer 1.0
- Log4Net 1.1
Dependencies With Total Version Range Conflicts
In the Feed:
-
SuperLogger 1.0, SuperLogger 1.1 (depend on log4net version 1.2 – 1.3 inclusive).
-
MyLogDisplayer 1.0 (depends on log4net 1.0 – 1.1 inclusive)
-
log4net 1.0, 1.1, 1.2, 1.3
Installed:
- SuperLogger 1.0
- MyLogDisplayer 1.0
- log4net 1.1
A slight variant of the previous case, in this case we already have log4net 1.1 installed, and as in the previous case, this cannot be upgraded to log4net 1.2. So nothing happens.
Result (Installed):
- SuperLogger 1.0
- MyLogDisplayer 1.0
- Log4Net 1.1