LaunchDarkly .NET SDK using MAUI artifacts on non-MAUI backend service application

[BorderKeeper]

Describe the bug
We are an non-MAUI app (part system service backend, part WPF UI frontend.) After we migrated from our 4.0.0 version of LD to 5.9.0 we noticed that the SDK stopped recognizing that the internet came back if you started the app without internet and then turned it back on. We have made a simple demonstrator console app and could reproduce this effect.

To reproduce

1. Plain .NET 9 console
2. Reference LaunchDarkly.ClientSdk 5.9.x.
3. Turn the WiFi off.
4. LdClient.Init(config, context, 10s). Init returns Initialized=false, DataSourceStatus=NetworkUnavailable, NetworkAccess=Local.
5. Turn the network back on.

Observed behaviour
polled NetworkAccess flips to Internet, but ConnectivityChanged never fires; DataSourceStatus stays NetworkUnavailable; evaluations keep returning the fallback. Never recovers.

Expected behavior
(similar to 4.0.0): reconnects, DataSourceStatus -> Valid, real value returned.

Logs
4.0.0 and 5.9.6 run.txt

SDK version
5.9.0 and 5.9.6 (but all that use MAUI libraries will be affected)

Language version, developer tools
.NET 9.0.

OS/platform
Windows 11

Additional context (code example used)

var config = Configuration.Builder(mobileKey, ConfigurationBuilder.AutoEnvAttributes.Disabled)
    .Persistence(Components.NoPersistence).Build();
var client = LdClient.Init(config, ctx, TimeSpan.FromSeconds(10));   // network is OFF here
client.DataSourceStatusProvider.StatusChanged += (s, st) => Log($"status -> {st.State}");
client.FlagTracker.FlagValueChanged += (s, e) => Log($"FlagValueChanged {e.Key} -> {e.NewValue}");
// then poll every 2s: client.DataSourceStatusProvider.Status.State and client.BoolVariation(flag,false)
// turn network back ON mid-run and observe.

I would be very appreciative if the MAUI requirement was dropped from this SDK. Most .NET applications relying on Launch Darkly are not running MAUI, or even any UI layer at all and are unable to use Launch Darkly at all due to this. Also apologizes I marked it as package:sdk/server but you don't have a client package option available in the list.

[tanderson-ld]

Hi @BorderKeeper , thank you for reaching out. Does this workaround work for you? If necessary, I can help find versions.

[BorderKeeper]

Yep forcing the fallback to netstandard libraries seemed to have done the trick thanks. Can you vouch for this workaround, we have thousands of devices in our fleet and if unsure I would rather fallback to pre MAUI version, which seems to be versions older than 5.0.0.

FYI I think you are doing it in the workaround as well but maybe if it helps we had to do this as well which is similar:

<!-- LaunchDarkly.ClientSdk 5.x transitively pulls Microsoft.Maui.Essentials, whose MSBuild 
         targets activate MSIX/MRT/PRI resource tooling on any project targeting net*-windows. 
         That tooling then demands RuntimeIdentifiers, SkipGetTargetFrameworkProperties on 
         C++/CLI ProjectReferences, and AppxGeneratePriEnabled/EnableCoreMrtTooling opt-outs 
         throughout the solution. ExcludeAssets on build;buildTransitive keeps LD's runtime 
         DLLs but blocks the MAUI build-time infrastructure from leaking in. --> 
<PackageReference Include="LaunchDarkly.ClientSdk" Version="5.9.0"> 
         <ExcludeAssets>build;buildTransitive</ExcludeAssets> 
</PackageReference>

[tanderson-ld]

Yes, our intent is to support Net Standard implementations so that non-UI applications can continue to use LaunchDarkly. The Net Standard classes in the SDK assume there is connectivity to avoid issues.

This workaround only became necessary in 5.x due to the package resolution ambiguity. We will likely revise the package resolution in our next major version.

I think ExcludeAssets="Compile;Runtime;BuildTransitive" /> is the minimum necessary, but All may also work.

[BorderKeeper]

Thanks will talk with the team, but most likely upgrade in that case. Feel free to close this ticket or leave it up for others who may stumble upon this as the existing open issues none seem to behave or describe a similar issues, it's mostly compilation issues.

[tanderson-ld]

Thank you for reaching out. I am leaving this issue open to help others that may run into this issue find the above workaround.