Issues with NuGet package updates


  • When doing an update-package on EPiServer Commerce the process can fail with a message like “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’.”
  • This problem is caused by a bug in NuGet 2.x, which will most likely be fixed in NuGet 3 (see below for more details). However, it seems like the bug will not be fixed in NuGet 2.x.
  • The problem seems to occur in later releases of CMS (8), Commerce (8.8) and Find (9), but might appear in earlier versions as well, depending on the upgrading path.
  • The workaround is to update the individual packages one-by-one, when upgrading EPiServer.

The problem

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.

The workaround

If you see this problem the workaround is to update the individual packages to the desired version. In the specific scenario described above, you simply update the EPiServer.Framework package to version 8.0, which will trigger update of other packages to the expected versions.

What’s next?

The bug has been reported in the NuGet 3 repo. The issue was closed as it was considered to be solved with NuGet 3.

NuGet 3 is more or less completely rewritten and the package resolving algorithm is very different. We have, to the best of our understanding of the new code, verified in a unit test that the reduced scenario described above is indeed working. Unfortunately we are unable to verify the “real world” scenario because of other bugs in the current NuGet 3 beta.

The bug has also been reported on NuGet 2.x, but most likely will not be addressed in NuGet 2.x, with NuGet 3 just around the corner.

Source: Issues with NuGet package updates