Rx 7.0 packaging changes

Rx.NET/Documentation/IntroToRx/03_CreatingObservableSequences.md

@@ -1072,7 +1072,7 @@ As you can see the `ISubject` interfaces don't define any members of their own.
 
 But what is this for? You can think of `IObserver<T>` and the `IObservable<T>` as the 'consumer' and 'publisher' interfaces respectively. A subject, then is both a consumer and a publisher. Data flows both into and out of a subject.
 
-Rx offers a few subject implementations that can occasionally be useful in code that wants to make an `IObservable<T>` available. Although `Observable.Create` is usually the preferred way to do this, there's one important case where a subject might make more sense: if you have some code that discovers events of interest (e.g., by using the client API for some messaging technology) and wants to make them available through an `IObservable<T>`, subjects can sometimes provide a more convenient way to to this than with `Observable.Create` or a custom implementation.
+Rx offers a few subject implementations that can occasionally be useful in code that wants to make an `IObservable<T>` available. Although `Observable.Create` is usually the preferred way to do this, there's one important case where a subject might make more sense: if you have some code that discovers events of interest (e.g., by using the client API for some messaging technology) and wants to make them available through an `IObservable<T>`, subjects can sometimes provide a more convenient way to do this than with `Observable.Create` or a custom implementation.
 
 Rx offers a few subject types. We'll start with the most straightforward one to understand.
 

Rx.NET/Documentation/ReleaseHistory/Rx.v7.md

@@ -0,0 +1,49 @@
+# Rx Release History v7.0
+
+## 7.0.0
+
+Supported on .NET 8, .NET 9, and .NET 10.0.
+
+New features:
+
+* Applications with a Windows-specific TFM (e.g., `net8.0-windows.10.0.19041`) can now reference the `System.Reactive` package without automatically acquiring a reference to the `Microsoft.Desktop.App` framework (which includes WPF and WinForms). If the application uses either self-contained deployment or AoT, this fixes the problem in which a reference to Rx would massively increase the size of the deployable application.
+
+
+### Breaking changes
+
+* UI-framework-specific functionality now requires referencing the relevant platform-specific package:
+  * `System.Reactive.Windows.Forms` for Windows Forms
+  * `System.Reactive.Wpf` for WPF
+  * `System.Reactive.WindowsRuntime` for WinRT (e.g., `CoreDispatcher`) support
+* If an application with a Windows-specific TFM had been relying on `System.Reactive` to acquire the `Microsoft.Desktop.App` framework dependency, it will need to add `<UseWPF>true</UseWPF>` or `<UseWindowsForms>true</UseWindowsForms>`
+* Out-of-support target frameworks (.NET 6.0, .NET 7.0) no longer supported
+
+Note that the packaging changes for UI-specific functionality constitute a source-level breaking change, but not a binary-level breaking change. Although the UI-framework-specific types have been removed from the public API of `System.Reactive`, they remain present at runtime. (The NuGet package has both `ref` and `lib` folders. The .NET build tools use the `ref` folder at compile time, and these types have been removed only from the `ref` assemblies. At runtime the `lib` folder is used, and the full API of `System.Reactive` v6 remains available in the assemblies in `lib`. Thus existing binaries built against Rx 6.0 that find themselves using Rx 7.0 at runtime will continue to work.)
+
+`System.Reactive` has an analyzer that detects when a project has a build error because it was using UI-specific functionality that used to be in `System.Reactive` but now lives in a new package that the project does not yet reference. The analyzer produces diagnostics telling the developer what new reference they will require.
+
+
+### Deprecation of facades
+
+Back in Rx 4.0 (the last time there was a major upheaval to the packaging), various NuGet packages that had previously been core components of Rx.NET were demoted to compatibility facades. These contained just type forwarders indicating that the various types they used to define have moved into `System.Reactive`.
+
+These packages existed to enable code built against older versions of Rx.NET to continue to work when upgraded to Rx 4.0 or later. We have continued to build new versions of these with each subsequent version of .NET, but all that has typically changed is the exact versions in the TFMs. Nobody should be using these facades any more so there is no reason to continue to produce new ones. (And anyone who is still using the old ones can continue to do so.)
+
+So we no longer produce new versions of these packages.
+
+* `System.Reactive.Compatibility`
+* `System.Reactive.Core`
+* `System.Reactive.Experimental`
+* `System.Reactive.Interfaces`
+* `System.Reactive.Linq`
+* `System.Reactive.PlatformServices`
+* `System.Reactive.Providers`
+* `System.Reactive.Runtime.Remoting`
+* `System.Reactive.Windows.Threading`
+
+Note that these packages were for many years facades:
+
+* `System.Reactive.Windows.Forms`
+* `System.Reactive.WindowsRuntime`
+
+With Rx 7, these have returned to their original roles: they are now the home of Windows Forms and WinRT support in Rx. (We have not resurrected the `System.Reactive.Windows.Threading` package, because its name is a somewhat unhelpful accident of history. WPF functionality now lives in the new `System.Reactive.Wpf` component.)

Rx.NET/Documentation/adr/0003-uap-targets.md

@@ -127,6 +127,18 @@ Without these explicit settings, those first two values would have become `UAP,V
 
 However, only _some_ properties should use the old name. We need to set _all_ of these properties, because otherwise, other parts of the build system get confused (e.g., NuGet handling). So we need the ".NETCore" name in some places, and the "UAP" name in others.
 
+Also note that the package validation tooling (which we use to ensure that `System.Reactive` continues to present the same API as it always did) turns out not to understand the `.NETCore,Version=v5.0` TFM. So for that to work, we need to put the TFM back how it was later in the build process, which is why we have this target:
+
+```xml
+<Target Name="_SetUwpTfmForPackageValidation" BeforeTargets="RunPackageValidation">
+<ItemGroup>
+    <PackageValidationReferencePath Condition="%(PackageValidationReferencePath.TargetFrameworkMoniker) == '.NETCore,Version=v5.0'" TargetFrameworkMoniker="UAP,Version=10.0.18362.0" TargetPlatformMoniker="Windows,Version=10.0.18362.0" />
+</ItemGroup>
+</Target>
+```
+
+This also sets the target platform moniker to indicate that this is a Windows-specific TFM, something that the package validation tooling doesn't seem to understand otherwise. (But we do need the target platform identifier to be `UAP` earlier on in the build for various other things to work, which is why we only switch this just before package validation runs.)
+
 
 #### Compiler Constants