search
AI OnAI Off
EPiServer.Commerce.Core 14.46.0 build validation fails with "EPiServer.Find.Commerce version 0.0.0 is not compatible" when using NuGet Central Package
Vote:
Thanks, I encountered the same issue. Have you reported this bug to Optimizely support?
Below is my temporarily fix before Optimizely official release the fix, I hope it helps.
<Project><!--EPiServer.Commerce.Core ships a buildTransitive compatibility check that reads theVersion metadata directly off the EPiServer.Find.Commerce PackageReference item.Under Central Package Management that metadata is empty at evaluation time (versionscome from Directory.Packages.props instead), so the vendor check always sees "0.0.0"and fails the build. Populate the metadata from the central PackageVersion before thevendor target runs.--><Target Name="_FixEPiServerFindCommerceVersionMetadata"BeforeTargets="_CheckFindCommerceCompatibility"Condition="'@(PackageReference->WithMetadataValue('Identity','EPiServer.Find.Commerce'))' != ''"><PropertyGroup><_FindCommerceCentralVersion>@(PackageVersion->WithMetadataValue('Identity','EPiServer.Find.Commerce')->Metadata('Version'))</_FindCommerceCentralVersion></PropertyGroup><ItemGroup><PackageReference Update="EPiServer.Find.Commerce" Version="$(_FindCommerceCentralVersion)" /></ItemGroup></Target></Project>
Edited,
Aug 10, 2026 23:52
Summary
The _CheckFindCommerceCompatibility MSBuild target shipped in EPiServer.Commerce.Core 14.46.0 (buildTransitive/net8.0/EPiServer.Commerce.Core.targets) hard-fails the build for any solution that uses NuGet Central Package Management (CPM), even when a compatible EPiServer.Find.Commerce version (≥ 12.3.0) is correctly resolved.
Error
/…/.nuget/packages/episerver.commerce.core/14.46.0/buildTransitive/net8.0/EPiServer.Commerce.Core.targets(27,5):error : EPiServer.Find.Commerce version 0.0.0 is not compatible with the current EPiServer.Commerce version.Please upgrade EPiServer.Find.Commerce to version 12.3.0 or later.Environment
Root cause
The target reads the version from the Version metadata of the PackageReference item:
<_FindCommerceRawVersion>%(_FindCommerceRef.Version)</_FindCommerceRawVersion><_FindCommerceRawVersion Condition="'$(_FindCommerceRawVersion)' == ''">0.0.0</_FindCommerceRawVersion>Under Central Package Management, PackageReference items intentionally carry no Version metadata — versions are declared on PackageVersion items in Directory.Packages.props. The metadata is therefore always empty, the check falls back to 0.0.0, and the <Error> fires unconditionally. The actual resolved version (visible in project.assets.json / packages.lock.json) is never consulted, so every CPM solution referencing EPiServer.Find.Commerce fails to build regardless of the version used.
Steps to reproduce
Expected behavior
The compatibility check should recognize the centrally managed version — e.g. by also reading @(PackageVersion) (and VersionOverride metadata) when $(ManagePackageVersionsCentrally) is true, or by validating against restore output instead of raw item metadata.
Workaround we are using
Overriding the target in Directory.Build.targets (imported after package targets, so the same-named target replaces the shipped one) with an equivalent check that reads the version from the PackageVersion item instead.
Additional note
Related packaging gap: EPiServer.ContentDeliveryApi.Search 3.12.7 (latest) still constrains EPiServer.Find.Cms to >= 16.0.0 && < 17.0.0, producing NU1608 warnings for every project when used with the current EPiServer.Find.Cms 17.0.1.