Rx 7.0 RC1 available

[idg10]

On 2026/06/18 we published System.Reactive v7.0.0-rc1 to NuGet. It can reduce the size of self-contained applications that use Rx by up to 90MB!

We've been running various tests on it, and we believe it is ready to go. Our plan is to publish 7.0.0 in mid July.

If you depend on Rx, we encourage you to try this out, and let us know if you have any problems.

What changed?

We have exactly one goal with this release: to fix the 'bloat' problems that System.Reactive causes for Native AoT and self-contained deployment of applications that target Windows. (Adding System.Reactive could cause an application to grow by as much as 90MB!) This has been discussed extensively, originally at #2038 and then again at #2211 after our original plans turned out to have flaws.

You can see an extremely detailed discussion of the history the led up to this problem, and all the design options we considered, at https://github.com/dotnet/reactive/blob/main/Rx.NET/Documentation/adr/0005-package-split.md

What will this mean for me?

That depends on what sort of application you've written.

Applications without a Windows-specific target framework

If your application's target framework is not Windows-specific, this update should not change anything at all. You should be able to upgrade with no change in behaviour. For example, if your project file contains something like this:

<TargetFramework>net10.0</TargetFramework>

then the upgrade to Rx 7.0 should have no discernible effect.

Applications not using Rx's UI features, but which have a Windows TFM

If you are building applications with a Windows-specific target framework (e.g. net10.0-windows10.0.19041.0) but which don't use WPF, Windows Forms, or UWP, then the only change you'll see is if you use either NativeAoT or self-contained deployment. With Rx 6.1 (or earlier versions back as far as 4.0), using System.Reactive would cause your deployable application to be much larger than necessary—as much as 90MB larger if you use self-contained deployment without trimming! You should find that this bloat no longer occurs. Adding System.Reactive 7.0 should add around one and a half megabytes to your output.

So this should be a very simple win: just upgrade to Rx 7.0, and your build output will shrink dramatically, but nothing else will change.

Applications using Rx's UI-framework-specific features

Historically, the System.Reactive NuGet package has included support for certain .NET UI frameworks. In Rx 6.1, we support WPF, Windows Forms, and the old type of UWP apps (the ones with a uap10 target framework). If you use any of these features, you will need to make a change when upgrading to 7.0: you'll need to add an extra NuGet package reference. You'll get a build warning telling you exactly which package you need.

We had to move the UI support out of the main System.Reactive package because baking this support directly into the main Rx package was the cause of the bloat problems: any .NET application with a Windows-specific TFM that added a reference to System.Reactive ended up acquiring dependencies on the WPF and Windows Forms UI frameworks. If you were using NativeAoT or self-contained deployment, the build system would then deploy a copy of both of these UI frameworks as part of your application.

But since UI-framework-specific features (such as the WPF-specific DispatcherScheduler type) are no longer available in System.Reactive, if your application uses any of these types, you will get compiler errors after upgrading to Rx 7.0.

System.Reactive 7.0 includes an analyzer that detects when errors of this kind occur, and tells you exactly which NuGet package to add. For example, if you had been using the DispatcherScheduler type, then as well as seeing this error:

error CS0234: The type or namespace name 'DispatcherScheduler' does not exist in the namespace 'System.Reactive.Concurrency' (are you missing an assembly reference?)

you will also see this message:

warning RXNET0002: The 'DispatcherScheduler' type has moved. Add a reference to the System.Reactive.Wpf NuGet package. (https://github.com/dotnet/reactive

If you follow that message's advice, (by adding a reference to the System.Reactive.Wpf NuGet package) that will fix the problem.

What about backwards compatibility?

You might be wondering what happens if you're using a library that depends on these UI-specific features of Rx 6.1, and you upgrade to Rx 7.0. For example, what if you're using ReactiveUI.WPF Version 23.2.28. It has an indirect dependency on Rx 6.1, and it uses the DispatcherScheduler in System.Reactive.

So if you upgrade your application to System.Reactive 7.0, in which we've removed the DispatcherScheduler, you might expect to get a runtime error complaining about a missing type. ReactiveUI.WPF is going to expect the DispatcherScheduler to be available in System.Reactive.

In fact it will be fine. We only removed the UI framework support from the public API. It's still there at runtime. We're able to do this because NuGet packages can supply separate 'reference' assemblies defining the public-facing API (in the ref folder inside the package), and we only removed the UI-framework-specific types from there. They continue to be available in the runtime assemblies (in the package's lib folder). This ensures binary backwards compatibility.

Stop using packages.config

There is one potential problem with the ref/lib split that we have used to remove types from the public-facing API while retaining them at runtime for binary compatibility: projects using the old packages.config mechanism do not use reference assemblies.

No new projects should ever use packages.config. It is an old and very problematic mechanism. Existing projects still using it would be well advised to move on. If you are unable to move on, then you might encounter compilation ambiguities if you end up with references to both System.Reactive and one of the UI-framework-specific packages such as System.Reactive.Wpf. Staying on Rx 6.1 is likely to be your easiest option, but if an upgrade is forced on you, you might be able to use reference aliases and the extern keyword to deal with this. But remaining on packages.config is not a scenario we support from now on.