version compatibility

[bdscarboro1]

In a .NET Web API project targeting .NET 8, the latest FeatureManagementProvider is not compatible with the latest OpenFeature SDK (v1.5.1)

• Running this from the project folder: dotnet add package OpenFeature.Contrib.Provider.FeatureManagement --version 0.0.1-pr.20240418T192045
  gives this message:
  warn : NU1603: FeatureFlagsWebApp depends on OpenFeature.Contrib.Provider.FeatureManagement (>= 0.0.1-pr.20240418T192045) but OpenFeature.Contrib.Provider.FeatureManagement 0.0.1-pr.20240418T192045 was not found. An approximate best match of OpenFeature.Contrib.Provider.FeatureManagement 0.0.1-preview was resolved.

• That same message is seen in Visual Studio's project dependencies tree under this node:
  OpenFeature.Contrib.Provider.FeatureManagement(0.0.1-preview)

• The project builds successfully, but gives that same warning message in the build output.

• The project runs, but when calling client.GetBooleanDetails, the FlagEvaluationDetails object returned has an ErrorMessage property with this value:
  "Method not found: 'Void OpenFeature.Model.ResolutionDetails`1..ctor(System.String, !0, OpenFeature.Constant.ErrorType, System.String, System.String, System.String)'."

• The end result is that all flags evaluated return false regardless of the values in appsettings.json

Of note, in this same project, same flags structure in appsettings.json, it all works correctly when using just Microsoft.FeatureManagement without OpenFeature.

[askpt]

I tried to replicate the build process issues, but I could not. You are trying to get the package from Nuget, but the version you are referencing is hosted on GitHub. Could you please try using this version: https://www.nuget.org/packages/OpenFeature.Contrib.Provider.FeatureManagement/0.0.1-preview

[bdscarboro1]

Thanks for the reply! I have tried that package as well, with the same result. Since then, I removed both packages, and just added a class for the implementation of the feature provider for MS.FeatureManagement, it's basically identical to the class FeatureManagementProvider from OpenFeature.Contrib.Providers.FeatureManagement. Now with that arrangement, the error message I was seeing in the FlagEvaluationDetails object is gone. But unfortunately, the flags are all still evaluating as false. So I'm starting to think I'm just not doing something correctly or something I'm not doing at all, that I should be. Are there any code samples out there that are applicable enough to this use case to be helpful?
Thanks!

[toddbaert]

Could this be related to the fact that we haven't built this provider since we merged this change?

I saw something similar with flagd because we were using a constructor for ResolutionDetails which only existed in OpenFeature SDK 1.5+, but the dependency required was only 1.4+

But yes, the version on nuget is a bit old and you're trying to download a preview version which only exists on github as @askpt mentioned. There's currently some changes in the pipeline for this provider here (also including some documentation). Once these are done we will re-release and you can see if that resolves your issue - unless you'd like to try one of the preview releases hosted on github. I published this version which is basically the pending release which might fix your issue.

[dalinicus]

Getting a similar issue with the ConfigCat provider. OpenFeature 1.5.1 / Config Cat Provider 0.0.2

[dalinicus]

I can't tell if this was explicitly expressed above, but it almost certainly due to the fact that the providers haven't been built since 1.5.x. C# bakes in default values into the callers' assembly, so when default values are changed and added, calling assemblies will continue to use the old values until its rebuilt with the new code.

In this case, a new default value was added, so the callers assembly (in this case, the configcat provider) no longer matches the downstream assembly's method signature, resulting in this error.

Rebuilding with the new version should solve this issue.

[toddbaert]

I will be releasing all providers this week to resolve this issue elsewhere.

Thanks @dalinicus for bringing it up.

[toddbaert]

I will be releasing all providers this week to resolve this issue elsewhere.

Thanks @dalinicus for bringing it up.

I've done this.