Release 9.0.0 · reactiveui/ReactiveUI.Binding.SourceGenerators

Summary

ReactiveUI.Binding 9.0.0 is a major version because the .NET 11 assemblies are built without runtime-async. The public API does not change.

In .NET 10 and older, the C# compiler adds a state machine to each async method. The state machine stores the local variables and tracks where to resume after each await.
.NET 11 adds a feature called runtime-async. The runtime does this work instead, so async code can run faster.
ReactiveUI.Binding 8.x built the .NET 11 assemblies with runtime-async on. The .NET 8 to 10 and .NET Framework assemblies never used it.
The feature needs a runtime that supports it. CoreCLR does, and Mono does not.
Blazor WebAssembly runs on Mono unless you opt into CoreCLR. Avalonia's browser apps, WASI, Android API levels 21 to 23, and apps that set UseMonoRuntime=true also run on Mono.
ReactiveUI.Binding built with runtime-async can fail in every app that runs on Mono.
A NuGet package ships one build for every runtime, so ReactiveUI.Binding leaves the feature off. This matches Refit 16.0.0.
Apps that target .NET 10 or older are not affected. Apps on .NET 11 that run on CoreCLR do not get the speed gain inside ReactiveUI.Binding's own async code.
You can turn on runtime-async in your own app if it runs only on CoreCLR.

BindCommandUnsafe and BindInteractionUnsafe now dispose the binding they replace when a link in the control chain changes. Before, each change added another live binding, so a command ran once per binding and stayed attached after disposal (#163).

cbb8e3c fix: dispose the displaced binding when BindCommandUnsafe rebinds (#165) @glennawatson

🔗 Full Changelog: v8.8.1...v9.0.0

💖 Thanks to all the contributors: @glennawatson

🤖 Automated services that contributed: renovate[bot]