Note: This information applies to EPiServer CMS 8 or later, Commerce 8 or later, and Find 9 or later.
- When doing an update-package on EPiServer Commerce, the process can fail with a message like "Updating 'EPiServer.CMS.Core 8.1.0' to 'EPiServer.CMS.Core 9.0.1' failed. Unable to find versions of 'EPiServer.Commerce.Core, EPiServer.Find.Cms' that are compatible with 'EPiServer.CMS.Core 9.0.1'."
- This problem is caused by a bug in NuGet 2.x, which is fixed in NuGet 3 (see below for more details). However, the bug will not be fixed in NuGet 2.x.
- The problem may occur when the update includes a new major version somewhere in the dependency graph, for example, the new version of the package being updated requires EPiServer.Framework 8.x instead of 7.x.
- Possible workarounds include using Visual Studio 2015 with NuGet 3.2, trying to update a different package first, or updating specific packages (see details below) with the –IgnoreDependencies option.
One specific scenario where we have been able to consistently reproduce the NuGet bug is with Commerce + FindSearchProvider 8.7.1 installed, and calling update on Commerce. That should install Commerce 8.8 (or later) which depends on CMS 8.0 and the corresponding FindSearchProvider depends on Find.Cms 9.0 (which depends on CMS 8.0). This fails with an "Updating 'EPiServer.Framework 7.19.1' to 'EPiServer.Framework 8.0' failed. Unable to find a version of 'EPiServer.Find.Cms' that is compatible with 'EPiServer.Framework 8.0'." or similar.
There are other scenarios as well where the bug has occurred. The bug has been reproduced with a fairly small unit test and the crucial part is when you have a "diamond-shaped" dependency graph like this:
In this case there are a few triggering factors:
- The package the update is triggered for is B (think of it as Commerce).
- The new version of B requires an updated version of D (CMS) which is incompatible with the old version of C (Find).
- The compatible version of C (Find) is incompatible with the old version of A (FindSearchProvider).
There is nothing abnormal about this dependency graph or the version restrictions, and it is not specific to EPiServer Commerce. However, the step-by-step algorithm of NuGet 2.x is unable to figure out all the required operations if it starts in the wrong place.
There are probably many sets of packages in the EPiServer sphere that can end up in this situation, but we do not see it on "vanilla" CMS sites, because those graphs are much simpler.
These are the workarounds you can attempt, in order of preference:
- Do the update using Visual Studio 2015 with NuGet Package Manager 3.2 (or later), if available.
- Try to update the individual packages instead of triggering a solution-wide or project-wide update of all packages.
- Try to update a different package first, for example, EPiServer.Framework instead of EPiServer.Commerce.
- Use the -IgnoreDependencies flag on specific packages (depending on what you have installed) before updating other packages. Note: Don’t use -IgnoreDependencies for all package updates, you may end up in a state where required dependencies are missing.
Packages that you can try to update while ignoring dependencies (depending on what you have installed):
Example: First update EPiServer.Packaging.UI ignoring dependencies, then update EPiServer.Commerce to get all other updated packages (with full dependency resolution).
Update-Package EPiServer.Packaging.UI –IgnoreDependencies
Last updated: Oct 20, 2016