<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/rx-net-7-0-reduces-deployment-size-by-splitting-windows-ui-support-dhutfs2of" -->

---
title: Rx.NET 7.0 Reduces Deployment Size by Splitting Windows...
description: Rx.NET 7.0 splits WPF, Windows Forms, UWP, and Windows Runtime integration out of the main System.Reactive NuGet package into separate packages, fixing an...
canonical: https://daily.dev/posts/rx-net-7-0-reduces-deployment-size-by-splitting-windows-ui-support-dhutfs2of
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Rx.NET 7.0 Reduces Deployment Size by Splitting Windows UI Support | daily.dev
og:description: Rx.NET 7.0 splits WPF, Windows Forms, UWP, and Windows Runtime integration out of the main System.Reactive NuGet package into separate packages, fixing an...
og:url: https://daily.dev/posts/rx-net-7-0-reduces-deployment-size-by-splitting-windows-ui-support-dhutfs2of
og:image: https://api.daily.dev/og/posts/dhUTfS2OF.png
og:image:alt: Rx.NET 7.0 Reduces Deployment Size by Splitting Windows UI Support
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Rx.NET 7.0 Reduces Deployment Size by Splitting Windows UI Support

**[InfoQ](https://daily.dev/sources/infoq)** · 3 min read · 5 upvotes · 0 comments

## Summary

Rx.NET 7.0 splits WPF, Windows Forms, UWP, and Windows Runtime integration out of the main System.Reactive NuGet package into separate packages, fixing an issue where self-contained or Native AOT applications targeting Windows-specific TFMs could pick up 11-90 MB of unused UI framework dependencies. Applications that use those UI integrations must add the corresponding package explicitly after upgrading; a bundled analyzer flags affected code. Binary compatibility is largely preserved since old UI APIs remain in runtime assemblies but are removed from reference assemblies, so precompiled Rx.NET 6.1 components keep working while new code can't accidentally depend on Windows UI features. The release also drops .NET 6 and .NET 7 support, keeps .NET 8/9/10, .NET Framework 4.7.2, .NET Standard 2.0, and UWP, and fixes nullability annotations on OfType, which forced a major version bump under semver. One edge case remains for projects using packages.config, which can still see UI APIs without an explicit reference since it doesn't distinguish NuGet ref and lib assets.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://www.infoq.com/news/2026/08/rx-net-7>

## Questions this post answers

### Why did referencing System.Reactive bloat my self-contained or Native AOT WPF deployment by dozens of megabytes?

Rx.NET versions before 7.0 bundled WPF, Windows Forms, UWP, and Windows Runtime integration directly inside the System.Reactive package. With a Windows-specific target framework moniker like net8.0-windows10.0.19041, self-contained or Native AOT deployments could pull in the complete WPF and Windows Forms frameworks even when unused, adding roughly 90 MB without trimming, about 47 MB with trimming, and around 11 MB for Native AOT builds.

_daily.dev surfaces fixes like this for teams chasing down bloated .NET deployment sizes._

### What do I need to change to upgrade from Rx.NET 6.1 to Rx.NET 7.0?

Applications that use WPF, Windows Forms, UWP, or Windows Runtime integration must explicitly add the corresponding new package: System.Reactive.Windows.Forms, System.Reactive.Wpf, System.Reactive.WindowsRuntime, or System.Reactive.Uwp, since those APIs were split out of System.Reactive. Rx.NET 7.0 also drops .NET 6 and .NET 7 support and fixes OfType's nullability annotations, a signature change with no behavior difference. An included analyzer detects affected code and recommends the package to add.

_Track breaking changes like this Rx.NET split before they surprise your build on daily.dev._

### Will my precompiled Rx.NET 6.1 components still work after upgrading to Rx.NET 7.0?

Yes, precompiled components built against Rx.NET 6.1 should continue to run because the older Windows UI APIs remain in the runtime assemblies shipped in the NuGet package, even though they were removed from the package's reference assemblies. This prevents newly compiled applications from accidentally depending on Windows UI functionality, while preserving binary compatibility for existing builds.

_Developers managing library upgrades weigh compatibility trade-offs like this one on daily.dev._

## Similar posts on daily.dev

- [Microsoft Releases .NET 11 Preview 6 With Language and Framework Updates](https://daily.dev/posts/microsoft-releases-net-11-preview-6-with-language-and-framework-updates-oqwjdzv3l) · InfoQ · 6 upvotes · 0 comments

---

Tags: [#.net](https://daily.dev/tags/.net), [#reactive-programming](https://daily.dev/tags/reactive-programming), [#nuget](https://daily.dev/tags/nuget)

[View this post on daily.dev](https://daily.dev/posts/rx-net-7-0-reduces-deployment-size-by-splitting-windows-ui-support-dhutfs2of)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Rx.NET 7.0 Reduces Deployment Size by Splitting Windows UI Support","url":"https://daily.dev/posts/rx-net-7-0-reduces-deployment-size-by-splitting-windows-ui-support-dhutfs2of","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/rx-net-7-0-reduces-deployment-size-by-splitting-windows-ui-support-dhutfs2of"},"datePublished":"2026-08-14T08:07:41.758Z","dateModified":"2026-09-14T07:06:39.811Z","description":"Rx.NET 7.0 splits WPF, Windows Forms, UWP, and Windows Runtime integration out of the main System.Reactive NuGet package into separate packages, fixing an...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/faba3e256366c7ca8bf65a5537a6504a?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/faba3e256366c7ca8bf65a5537a6504a?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"InfoQ","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"InfoQ","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/afc3bced3e1e4b188dd9127017a60e0c","url":"https://daily.dev/sources/infoq"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/rx-net-7-0-reduces-deployment-size-by-splitting-windows-ui-support-dhutfs2of","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":5},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":".net,reactive-programming,nuget","timeRequired":"PT3M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"InfoQ","item":"https://daily.dev/sources/infoq"},{"@type":"ListItem","position":3,"name":"Rx.NET 7.0 Reduces Deployment Size by Splitting Windows UI Support"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/rx-net-7-0-reduces-deployment-size-by-splitting-windows-ui-support-dhutfs2of#faq","mainEntity":[{"@type":"Question","name":"Why did referencing System.Reactive bloat my self-contained or Native AOT WPF deployment by dozens of megabytes?","acceptedAnswer":{"@type":"Answer","text":"Rx.NET versions before 7.0 bundled WPF, Windows Forms, UWP, and Windows Runtime integration directly inside the System.Reactive package. With a Windows-specific target framework moniker like net8.0-windows10.0.19041, self-contained or Native AOT deployments could pull in the complete WPF and Windows Forms frameworks even when unused, adding roughly 90 MB without trimming, about 47 MB with trimming, and around 11 MB for Native AOT builds. daily.dev surfaces fixes like this for teams chasing down bloated .NET deployment sizes."}},{"@type":"Question","name":"What do I need to change to upgrade from Rx.NET 6.1 to Rx.NET 7.0?","acceptedAnswer":{"@type":"Answer","text":"Applications that use WPF, Windows Forms, UWP, or Windows Runtime integration must explicitly add the corresponding new package: System.Reactive.Windows.Forms, System.Reactive.Wpf, System.Reactive.WindowsRuntime, or System.Reactive.Uwp, since those APIs were split out of System.Reactive. Rx.NET 7.0 also drops .NET 6 and .NET 7 support and fixes OfType's nullability annotations, a signature change with no behavior difference. An included analyzer detects affected code and recommends the package to add. Track breaking changes like this Rx.NET split before they surprise your build on daily.dev."}},{"@type":"Question","name":"Will my precompiled Rx.NET 6.1 components still work after upgrading to Rx.NET 7.0?","acceptedAnswer":{"@type":"Answer","text":"Yes, precompiled components built against Rx.NET 6.1 should continue to run because the older Windows UI APIs remain in the runtime assemblies shipped in the NuGet package, even though they were removed from the package's reference assemblies. This prevents newly compiled applications from accidentally depending on Windows UI functionality, while preserving binary compatibility for existing builds. Developers managing library upgrades weigh compatibility trade-offs like this one on daily.dev."}}]}
```

