dotnet/reactive: Rx.NET, Ix.NET and the LINQ-over-streams libraries in one repository

Four packages, one idea: LINQ where the data has not arrived yet

The README states the repository contains four libraries that are 'all concerned with LINQ over sequences of things'. The problem they address is stated just as plainly: most languages have a built-in way to work with lists, and those mechanisms 'tend to presume that the relevant data is already sitting in memory'. What is missing is liveness, the fact that a source may produce new data at any moment on its own schedule. Rx.NET is the event-driven library built on that premise, published as System.Reactive. AsyncRx.NET, published as System.Reactive.Async, is described as an experimental preview offering deeper async/await support over IAsyncObservable<T>. Ix.NET, published as System.Interactive, provides extended LINQ operators for IAsyncEnumerable and IEnumerable. System.Linq.Async implements the standard LINQ operators for IAsyncEnumerable. The audience is .NET developers writing code that responds to events: the README names cloud-native applications, IoT and real-time stream processing among the use cases, and points to a free second edition of Introduction to Rx.NET written against Rx.NET v6.0 and .NET 8.0.

How the Rx.NET model moves data from source to subscriber

The README frames Rx as a composable, declarative model for event-driven programming, and the repository structure backs the split. Rx.NET/ holds the main library, AsyncRx.NET/ the experimental one, Ix.NET/ the interactive extensions with System.Linq.Async nested inside it at Ix.NET/Source/System.Linq.Async/. That layout matters because the four packages version and ship independently: the release history for Rx lives under Rx.NET/Documentation/ReleaseHistory/ and the release history for Ix and System.Linq.Async under Ix.NET/Documentation/ReleaseHistory/. The data flow is the familiar push model: a source produces values over time, operators compose transformations over that stream, and a subscriber receives them. AsyncRx.NET changes the shape of the contract by moving from IObservable<T> to IAsyncObservable<T>, which is why the README calls it experimental rather than a replacement. Ix.NET sits on the other side of the line: it extends LINQ for sequences you pull from, including IAsyncEnumerable, so it is about consuming sequences asynchronously rather than subscribing to pushed events.

Installing System.Reactive and writing a first subscription

The README points at NuGet.org for all four packages and also lists a nightly feed. The package for the main library is System.Reactive, so the install is a standard package reference.

dotnet add package System.Reactive

After the restore completes, the package is available to your project and you can add a using directive for the System.Reactive.Linq namespace. The README gives the introduction book as the place to learn the abstractions, and that book is available online at introtorx.com, on GitHub under Rx.NET/Documentation/IntroToRx/, and as PDF and EPUB downloads. It is written against Rx.NET v6.0 and .NET 8.0, so if you are starting on the current line, expect to read it as background rather than as a version-matched reference. For the other packages the install follows the same shape with a different package name: System.Reactive.Async for the experimental async implementation, System.Interactive for the extended operators, and System.Linq.Async for the LINQ operators over IAsyncEnumerable. If you want builds newer than the published releases, the README says to configure NuGet with the feed URL https://pkgs.dev.azure.com/dotnet/Rx.NET/_packaging/RxNet/nuget/v3/index.json.

Where Rx.NET is the wrong tool

The clearest boundary is the one the README draws itself. Rx exists because list handling assumes the data is already in memory. If that assumption holds for your case, a bounded collection you already have, then the push model adds scheduling, subscription lifetime and disposal semantics you did not ask for. Plain LINQ over IEnumerable is easier to read and easier to debug, and Ix.NET exists precisely to cover the middle ground where the sequence is asynchronous but still pulled rather than pushed. The second boundary is AsyncRx.NET. The README labels it an experimental preview, so treating it as a production dependency carries the risk that comes with that label; the release history for it is not linked in the same table row as the other three. A third constraint is organisational rather than technical: the repository is four libraries with separate release histories and separate CI pipelines (azure-pipelines.rx.yml, azure-pipelines.ix.yml, azure-pipelines.asyncrx.yml). If your team adopts one, do not assume a version bump elsewhere in the repository tells you anything about it.

Ix.NET and System.Linq.Async versus pulling with plain LINQ

The real alternative inside this same repository is the pull side. Ix.NET, shipped as System.Interactive, provides extended LINQ operators for IAsyncEnumerable and IEnumerable, and System.Linq.Async implements the standard LINQ operators for IAsyncEnumerable. The difference in approach is direction of control. With Rx you subscribe and the source decides when values arrive; with IAsyncEnumerable you await the next element and your code decides when to ask. For a database cursor, a file being read in chunks, or any source where backpressure is naturally handled by not requesting the next item, the pull model is the simpler fit and it needs no subscription to dispose. Rx earns its place when the source is genuinely event-shaped: UI interactions, telemetry arriving on its own schedule, or several streams that need to be combined. The README's own framing supports that reading, since it describes Rx as the answer to sources that produce data at any moment on their own schedule.

Licence, release cadence and what an upgrade costs

The repository is MIT licensed, with the licence text at LICENSE in the root. MIT is permissive, so the practical obligation is retaining the copyright and permission notice; that is a statement about the licence text, not legal advice, and anything beyond it belongs with your own counsel. On cadence, the most recent release in the README's release history is rxnet-v7.0.0 from 2026-07-17, preceded by rxnet-v7.0.0-rc.1 on 2026-06-18 and rxnet-v7.0.0-preview.20 on 2026-06-03. The last push to main was on 2026-09-21. The upgrade cost is not uniform across the four packages because they do not share a release history: a bump in Rx.NET tells you nothing about Ix.NET or System.Linq.Async, and the README's release history links point to two separate directories. Pin the versions you depend on and read the history for that specific package rather than the repository as a whole. The README also documents a nightly feed, which is useful for testing against unreleased builds but is a separate channel from NuGet.org.

Editorial conclusion

Adopt Rx.NET if your code already reacts to events and you want composition, scheduling and disposal handled by a library rather than by hand-rolled callbacks. Skip it if your data is a bounded list already in memory, where plain LINQ is simpler and the extra abstraction buys nothing. Before committing, verify which of the four packages you actually need, since the repository keeps them separate, and check the release history under Rx.NET/Documentation/ReleaseHistory and Ix.NET/Documentation/ReleaseHistory for the version you plan to pin. The last push to main was on 2026-09-21, so the repository is current, but that says nothing about the API surface you will be writing against.

Frequently asked questions

Official sources

1. dotnet/reactive on GitHub
2. License: MIT
3. Project website
4. README
5. Releases