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.
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
Create a project referencing EPiServer.Commerce 14.46.0 and EPiServer.Find.Commerce 12.3.0.
Enable CPM: set ManagePackageVersionsCentrally=true and move the versions to PackageVersion items in Directory.Packages.props.
dotnet build → the error above, despite 12.3.0 being resolved.
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.
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.