Exception thrown when using SemVer operator with Semver NuGet v3.0.0

[deepforest]

Given a project that is using Semver NuGet Version="3.0.0" explicitly:

.csproj

<PackageReference Include="Semver" Version="3.0.0" />

An exception is thrown by Flagsmith SDK when trying to evaluate a feature that is using this operator, locally (Local Evaluation Mode):

How to repro:

• Create new .NET 8.0 project (or 9.0)
• Add Semver ver 3.0.0 nuget
• Add Flagsmith 7.0.1 nuget
• Setup Flagsmith to use Local Evaluation.
• Evaluate any flag with segment override with at least one SemVer operator.

Expected:
Feature successfully evaluated.

Actual:
Exception is thrown when trying to evaluate locally.
Failed to access feature my-feature for identity FlagsmithDemo: Method not found: 'Boolean Semver.SemVersion.op_GreaterThan(Semver.SemVersion, Semver.SemVersion)'.

Suggestion:
Either upgrade to latest Semver and fix breaking changes, or better, do not use Semver, instead, implement the version comparison operators as part of the library.

The less 3rd-party NuGet being used, the less compatibility and dependency hell.

[matthewelwell]

Hi @deepforest, thanks for raising this. In all honestly, I am surprised that .NET's dependency resolution algorithm doesn't error sooner than run time for this - in other languages, it would throw an error at build / compile time for example.

We will look into this, but I can't at this point say that we will be able to implement the functionality for the SemVer comparison logic in our client. In all of our other SDKs (apart from PHP, which provides it as a language built-in ❤ ) we use a third party library.

[deepforest]

Hi @deepforest, thanks for raising this. In all honestly, I am surprised that .NET's dependency resolution algorithm doesn't error sooner than run time for this - in other languages, it would throw an error at build / compile time for example.

We will look into this, but I can't at this point say that we will be able to implement the functionality for the SemVer comparison logic in our client. In all of our other SDKs (apart from PHP, which provides it as a language built-in ❤ ) we use a third party library.

Indeed, "DLL Hell" still exists in .NET (core), not traditionally as it was/still with Windows Shared DLLs, yet, if you add NuGet packages, say X, Y, and X uses Z v1.0 while Y uses Z v2.0, you might have a runtime issue if Z v2.0 does breaking changes.
Same if you use NuGet X, which is using Z v1.0 but adding Z v2.0 explicitly to the project, as what happens in my bug description, you're screwed!
In some cases, VS/Rider or any CS compiler will log Warning. In this case, Nada!

[matthewelwell]

Understood, thanks @deepforest

The easier 'solution' on our side will be to upgrade to SemVer 3.0.0, but I suspect that will still cause issues with any applications that explicitly depend on SemVer 2.X which, according to the stats here, will be more prevalent than those that depend on 3.0.0.

In the meantime, are you able to downgrade your dependency specification to 2.x?

[deepforest]

Understood, thanks @deepforest

The easier 'solution' on our side will be to upgrade to SemVer 3.0.0, but I suspect that will still cause issues with any applications that explicitly depend on SemVer 2.X which, according to the stats here, will be more prevalent than those that depend on 3.0.0.

In the meantime, are you able to downgrade your dependency specification to 2.x?

Yes, this is a complete .NET disaster!
Well, I'm not sure. We provide a NuGet package to all of our development teams to be used with dozens of services we have, some .NET and some .NET Framework. I need to check if we have any service that is using Semver 3.0 and if using Semver all.

[zachaysan]

I need to check if we have any service that is using Semver 3.0 and if using Semver all.

Ok sounds good @deepforest. Let us know if there is anything else you need.