Rx 7.0 now available

[idg10]

This month (July 2026) we released a new major version of Rx.NET. You can get System.Reactive v7.0.0 from NuGet today.

This fixes the long-standing bloat issues discussed extensively in Future Rx.NET Packaging. Applications that ran into this problem will find Rx 7 reduces the size of application deployments by as much as 95MB! The full history is explained in ADR 0005.

This release also withdraws support for .NET 6 and .NET 7 (which Microsoft stopped supporting some time ago). We currently support Rx 7 on .NET 8, 9, and 10. When .NET 11 ships, we will support that too.

We've made this video about the changes in Rx 7, and also a blog about the Rx 7 release.

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, and you are using a version of .NET that is currently supported (.NET 8.0 or later, or .NET Framework 4.7.2 or later) 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 95MB 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 (the size of System.Reactive.dll) 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.

Other changes

As noted earlier, we have removed support for .NET 6 and .NET 7.

We have also fixed the incorrect nullability annotation for the OfType operator, as reported in #2247 and #1525

[regolas]

Thanks for this great summary and congratulations on the release. Looking forward to using it

…

On Wed, Jul 29, 2026, 03:56 Ian Griffiths ***@***.***> wrote: This month (July 2026) we released a new major version of Rx.NET. You can get System.Reactive v7.0.0 <https://www.nuget.org/packages/System.Reactive/7.0.0> from NuGet today. This fixes the long-standing bloat issues discussed extensively in Future Rx.NET Packaging <#2038>. Applications that ran into this problem will find *Rx 7 reduces the size of application deployments by as much as 95MB!* The full history is explained in ADR 0005 <https://github.com/dotnet/reactive/blob/main/Rx.NET/Documentation/adr/0005-package-split.md> . This release also withdraws support for .NET 6 and .NET 7 (which Microsoft stopped supporting some time ago). We currently support Rx 7 on .NET 8, 9, and 10. When .NET 11 ships, we will support that too. 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, and you are using a version of .NET that is currently supported (.NET 8.0 or later, or .NET Framework 4.7.2 or later) 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 95MB 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 (the size of System.Reactive.dll) 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 <https://www.nuget.org/packages/ReactiveUI.WPF/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. Other changes As noted earlier, we have removed support for .NET 6 and .NET 7. We have also fixed the incorrect nullability annotation for the OfType operator, as reported in #2247 <#2247> and #1525 <#1525> — Reply to this email directly, view it on GitHub <#2338?email_source=notifications&email_token=ADGQ6PUUMNZ5XHFRNP2KYZ35HHC6DA5CNFSNUABBM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPGEYDKMJXGYYTPJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGQ6PV457CMYXRISUX7YLD5HHC6DAVCNFSNUABHKJSXA33TNF2G64TZHMYTENJXGY2TENR3IRUXGY3VONZWS33OHMYTANJRG43DCN5BOYBA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>