Packaging Plans July 2025

[idg10]

Our previous announcement that we were going to be moving forward with a new packaging plan for Rx.NET turned out to be premature. The plan, whose main goal is to fix the 'deployment bloat' issues that have led to some projects to abandon Rx, was predicated on the availability of a workaround for this problem, and as @kmgallahan pointed out, that workaround turned out not to work in some important cases. So we needed a less conservative plan.

Update I've recorded a video covering this update: https://www.youtube.com/watch?v=GSDspWHo0bo

Executive Summary

We have two main candidates for how to fix the current packaging problems. One retains System.Reactive as the main Rx package, and the other involves turning that into a legacy facade, and introducing a new main package, possibly called System.Reactive.Net.

We have introduced a new testing approach to validate possible designs, and it provides evidence showing that both of these seem to solve the problems at hand. Both have significant problems.

The main problem with turning System.Reactive into a legacy facade is that if applications end up with a reference to the old (non-facade) System.Reactive v6 and also to System.Reactive.Net v7, then there will be two complete implementations of Rx.NET in scope simultaneously. Any time you try to use one of Rx's extension methods, the compiler will complain that the code is ambiguous—it won't know which of the two implementations you want. (This is actually very easy to fix: just add a reference to System.Reactive v7, and its type forwarders effectively unify you back to a single implementation. But discovering this simple fix might be tricky for app authors. Even if we added a code analyzer in System.Reactive.Net to detect this situation and tell you exactly how to fix it, it is certainly disruptive.)

So retaining System.Reactive as the main package is attractive. However, there's one major problem: to do so, we have to use a 'clever' trick involving reference assemblies. 'Clever' tricks have a way of coming back to haunt us—this seems like exactly the sort of thing that might lead to another set of revisions to the packaging designs in a few years once all the unforeseen consequences of this approach become apparent. So we are very reluctant to employ such a trick in the main Rx assembly.

For that reason, we believe that relegating System.Reactive to being a legacy facade is the safer of these two options.

However, since the fears about the no-facade option are hypothetical, we are considering using that approach in Rx v7, because as far as we can tell, we would always be able to go to the safer design in Rx v8. (The no-facade design doesn't appear to close any doors. But turning System.Reactive into a legacy facade is a one-way trip.)

What We've Done

To try to avoid another premature declaration of victory, we've changed a couple of things about our approach:

1. we have created prototypes of various options, which are visible in branches in the Rx repo and which are available for download on the Rx.NET package feed, so the proposals are not merely hypothetical
2. we have written a test suite that checks for various problems Rx.NET has had in the past that we don't want to repeat, and also for various problems that we know some packaging design proposals have

Note: the Rx.NET package feed is open for anonymous access, but you might find you get an access denied error when you try to access it. This typically happens if you're already logged into Azure DevOps. If you're logged in, Azure DevOps tries to show you the full version of the feed page that project maintainers get to see, but then it realises you don't have access to that. For some reason, instead of just falling back to the version that's visible to anonymous users, it shows you an access denied error instead. If that happens, try opening a private browsing session—as long as Azure DevOps doesn't think it knows who you are, it will just show you the for-public-consumption version of the page.

'Rx Gauntlet' test suite

Although Rx.NET has long had a very comprehensive unit test suite, unit tests can't check for many of the packaging-related problems we've had in the past, and might have in the future, hence the need for this new kind of test suite. For this reason, we've added Rx Gauntlet.

This is currently visible only on the feature/rx-gauntlet branch, on which it can be found at https://github.com/dotnet/reactive/tree/feature/rx-gauntlet/Rx.NET/Test/Gauntlet

The key difference between this and more conventional tests it that this is able to create projects and build NuGet packages dynamically, and set up local NuGet package feeds. This enables automated testing of a wide range of build and deployment scenarios, including many subtle variations on situations where applications end up with indirect references to Rx.NET, possibly with a mix of version numbers, and in a way that application authors may not be able to control.

This is important because many of the problems with potential Rx.NET packaging design candidates is that they only fail in quite specific scenarios, and without testing all of them, it is impossible to be confident that certain kinds of problems have truly been eliminated.

Currently, the goal is to use Rx Gauntlet to test potential designs, so that we can be confident in whatever choice we ultimately make. In the longer term, Gauntlet's goal will be to avoid regressions of a kind that unit tests can't catch.

Packaging design option prototypes

Currently we've got four prototypes:

Preview Tag	Branch	Description
7.0.0-preview-legacyfacade.1.ga1159cd7f3	feature/packaging-systemreactive-as-facade	New System.Reactive.Net main package, new System.Reactive.For.Wpf/WindowsForms/Uwp packages; System.Reactive becomes a legacy facade consisting of type forwarders to these new components
7.0.0-preview-legacyfacade-refnoui.3.g7492bd514e	feature/packaging-systemreactive-as-facade-ref-no-ui	As above, but using a trick with reference assemblies to hide the UI-framework-specific types from the compiler in System.Reactive, enabling that component to drop its transitive dependency on theMicrosoft.Desktop.App framework
7.0.0-preview-legacyfacade-refnoui-withfxref.1.g307e3b7f27	feature/packaging-systemreactive-as-facade-ref-no-ui-with-fxref	As above, but with the transitive dependency on the Microsoft.Desktop.App framework still being present. This has better backwards compatibility, but you get bloat by default in scenarios where transitive dependencies mean you can't get rid of the legacy System.Reactive facade dependency. However, unlike System.Reactive v6, you can now prevent this with the <DisableTransitiveFrameworkReferences>.
7.0.0-preview-nofacade-refnoui.5.gc59ebd3e22	feature/packaging-no-facade-ref-no-ui	This does not introduce a new main Rx package. System.Reactive remains as the main package. It does not force a dependency on the Microsoft.Desktop.App. To make that work it uses the same reference assembly trick as the preceding two options.

To use these, you'll need a NuGetConfig.xml file pointing to the Rx.NET preview package feeds, e.g.:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="RxNet" value="https://pkgs.dev.azure.com/dotnet/Rx.NET/_packaging/RxNet/nuget/v3/index.json" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

We are open to adding more if people have new suggestions, or if they believe that suggestions we have already rejected should not have been. (E.g., there still seem to be some believers in the clean break, who do not seem to be convinced by arguments that this approach doesn't solve the problems at hand, and also creates new ones; so perhaps we will need to go actually prototype this option, so that the evidence that it doesn't work will be clear and incontrovertible.)

Analysis of test results

Rx Gauntlet produces large volumes of JSON summarizing its output, and it can be tricky to find the interesting results. We've therefore applied some processing to this.

We've created a PowerBI report that analyzes three of the four test types, and shows summarized results. The results of that are in RxGauntletResults.pdf.

The fourth category, transitive dependencies, is more complex. We have a Python notebook analyzing that. This PDF summarises its output: Packaging Options for Rx Notes.pdf

Our current position

Currently, we are trying to decide between two preferred options. One is to introduce a new main Rx package, relegating System.Reactive to being a facade, and the other is to modify System.Reactive but retain it as the main package.

System.Reactive as facade.

This is prototyped in the packaging-systemreactive-as-facade-ref-no-ui branch. In this, we:

• Introduce a new main Rx package (provisionally called System.Reactive.Net, but that could change if necessary)
• Add new UI-framework-specific packages such as System.Reactive.For.Wpf
• Relegate System.Reactive to a type forwarding legacy compatibility assembly, but using the reference assembly trick to make it possible for applications that can't avoid a dependency on this to escape from bloat by specifying DisableTransitiveFrameworkReferences; the trick we're using avoids the extension method problems that @kmgallahan identified

However, there are two major disadvantages:

1. a change to the main Rx assembly causes disruption and confusion
2. this change makes it possible for applications to end up with references to two different Rx.NET implementations simultaneously (by using System.Reactive.Net v7, but System.Reactive v6); it is easily resolved by upgrading the System.Reactive reference to v7, but it won't be obvious to people that this is what they need to do (unless we write a code analyzer to detect this problem and make the suggestion)

These are strong arguments in favour of the packaging-no-facade-ref-no-ui design.

Retain System.Reactive as main package.

The packaging-no-facade-ref-no-ui design is the less disruptive option. So why isn't it a slam dunk? It has two problems:

1. we are uncomfortable with the reference assembly hack; we're prepared to use it because it seems to be the only way to solve a particular problem, but while it's one thing to bake that into a package that is effectively being deprecated, we are not happy about the idea of baking this into the main Rx package
2. if System.Reactive continues to be the main Rx assembly, we will be doomed to have a uap10.0.18362 (old pre-.NET 9 UWP) target in the main Rx assembly for the foreseeable future, quite possibly for as long as a decade, and that TFM causes enormous trouble

This second aspect is arguably not that important because the pain falls entirely on people working on Rx.NET. If that were the only issue, we'd probably steel ourselves and just accept that we're going to have to live with that pain.

The first one is the major concern. The history of Rx's attempts to solve packaging issues with 'clever' unusual solutions is sobering. This has the potential to be the latest in a line of things that future Rx.NET maintainers wish had never happened.

Introducing a new main Rx package is the closest thing we have to a 'clean break' that can actually work, and it presents an opportunity to make the core Rx package normal: no clever tricks, no workaround, no weird off-label practices. This seems likely to maximise our changes of finally seeing an end to weird and hard to resolve problems.

However, while we believe that a new Rx package could well be the best long-term design overall, we recognize that there are significant benefits to retaining System.Reactive as the main Rx assembly, if that can be made to work. So...

Could We Try The No-Facade Approach First?

One possibility we are considering is trying the no-facade approach first despite some misgivings with it, and keeping the 'new main package' option as a fallback.

The idea here is that if we were to go ahead with the approach in which System.Reactive remains as the main package, and the 'clever' reference assembly trick turns out to cause problems, nothing stops us from turning it into a legacy facade in Rx 8 if we have to. This would make the Rx 7 release much less disruptive, and if our fears around the consequences of the trick turn out to be unfounded, then we've avoided an unnecessary introduction of yet another main Rx package.

The idea is that the two main candidates are non-commutative: it is possible to try the 'no-facade' approach first and then our preferred option second. But if we go straight for our preferred option, we can't go back to the no-facade approach later.

The main risk here would be that we've missed something: perhaps publishing the no-facade design as v7 ties our hands in some way that makes changing System.Reactive into a facade in v8 (should that prove necessary) harder.

[idg10]

To get a rough idea of what people think of this, please upvote this if you think Rx v7 should go straight to introducing a new main package, relegating System.Reactive to being a legacy facade.

This is as close to a 'clean break' as it gets.

[mwadams]

I prefer this option, if and only if we do build the analyzer that tells people how to fix their System.Reactive dependency issue.

I also wonder if there is a mechanism where we could detect whether WPF, WinForms etc. are in use in the project, and propose upgrades to reference the correct packages as an upgrade mechanism.

[idg10]

I also believe we would have to build such an analyzer if we did use this option.

I think a similar analyzer to detect UI-framework-specific usage and make appropriate recommendations would be required for either of the candidate design options. (In both designs, the UI types remain in the System.Reactive runtime assemblies for binary compatibility, but are absent in the reference assemblies—this is the one weird trick referred to throughout the summary above. So when a project that is using UI-framework-specific types directly upgrades to Rx 7, it will need to add System.Reactive.For.Wpf (or similar) for either of the two main designs we're considering. We did also prototype an option where that's not the case, but it has too many downsides.)

[glopesdev]

new System.Reactive.For.Wpf/WindowsForms/Uwp packages; System.Reactive becomes a legacy facade consisting of type forwarders to these new components

@idg10 One point of discussion I did not see addressed above is the naming and compatibility of the new platform-specific packages. Is this still up for discussion?

Are we looking at keeping just one legacy facade package? Or actually introducing several new overlapping packages for each supported platform? I feel the package ecosystem for Rx risks becoming increasingly confusing to navigate without a clear and systematic plan.

If we do end up with this option, can we deprecate the legacy facade packages? I don't think it makes sense to have so many packages side by side without some kind of guideposts pushing people to use the correct packages at package install time.

We did also prototype an option where that's not the case, but it has too many downsides.

Can you briefly elaborate on this option? What was the goal?

[idg10]

@glopesdev wrote:

naming and compatibility of the new platform-specific packages. Is this still up for discussion?

Naming of all packages remains open for discussion. There are constraints imposed by existing packages—there are the old packages that used to contain platform-specific code before the Great Unification, but which are now legacy facades. We can't turn those facades back into normal packages because this creates scenarios in which you can get circular type forwarder references. (That can happen when you end up with a mix of different versions being referenced.) And of course, whatever we do, there needs to be a package called System.Reactive, regardless of whether it continues to be the main package, or a legacy facade.

As for 'compatibility' of the new platform-specific packages, I'm not sure what you're referring to.

Are we looking at keeping just one legacy facade package? Or actually introducing several new overlapping packages for each supported platform?

System.Reactive would be the only package newly becoming a legacy facade. There would be a new main Rx package (tentatively called System.Reactive.Net in this prototype). In this, as with all options under consideration, we are introducing new packages to contain the platform-specific packages. Please could you clarify what you mean by 'overlapping' in this context because I don't understand the question?

can we deprecate the legacy facade packages

That seems like a good idea (no matter which design option we choose). It has now been a very long time since these were the correct way to use Rx, and with the re-introduction of some platform-specific packages, I agree that it's confusing for these older packages still to be there, so it would add some clarity to deprecate them, and point people at the new ones.

when a project that is using UI-framework-specific types directly upgrades to Rx 7, it will need to add System.Reactive.For.Wpf (or similar) for either of the two main designs we're considering. We did also prototype an option where that's not the case, but it has too many downsides.

Can you briefly elaborate on this option? What was the goal?

The goal was to minimise disruption on upgrade: in an ideal world, we would a) fix the bloat problems and b) arrange things so that when projects already using Rx upgrade from 6 to 7, they don't encounter any problems that require them to find out that they need to add additional references. Sometimes a) and b) are in conflict, so you sometimes have to prioritise one over the other, and this was an attempt to prioritise b) for apps where the main app code itself directly uses Rx's UI types.

The idea was to avoid the bloat problem by removing the framework reference to Microsoft.Desktop.App from System.Reactive but still providing all the WPF and Windows Forms types in the public API of System.Reactive. In theory, the only compatibility problem would then be if an application was using WPF or Windows Forms but had not specified <UseWPF>True</UseWPF> or <UseWindowsForms>true</UseWindowsForms> in their application project file, and had instead just relied on the fact that if you use System.Reactive v6 in a net8.0-windows10.0.19041 project, Rx effectively adds UseWPF and UseWindowsForms for you.

So in theory we we had just removed the framework reference from System.Reactive but left everything else the same, then only projects build that way would have an issue, which would easily be resolved by setting UseWPF or UseWindowsForms in their own project files. (And any WPF or Windows Forms project created with File New in Visual Studio already has one of these settings anyway, so very few apps are likely to be relying on Rx to set these properties anyway.)

But in practice it doesn't work well. You end up with platform-specific overloads being available and if you've not got the Microsoft.Desktop.App framework reference, using any method (e.g. ObserveOn) for which a WPF- or Window-Forms-specific overload exists will cause a compiler error even if you weren't actually trying to use one of those overloads. So any app with a Windows-specific TFM that uses Rx needs to reference the desktop framework to avoid these build errors, and thus you don't get to avoid the bloat. So it doesn't fix the problem, but it does mean people need to make changes to their project file to get things building after upgrading to Rx 7! So it's kind of the worst of both worlds. (The one scenario this does improve is where the app doesn't use Rx directly, but does acquire a dependency to it via other components.)

[idg10]

...and please upvote this if you think we should retain System.Reactive as the main package in Rx 7, employing the reference assembly trick to make that work, and retaining the option to turn it into a legacy facade in v8 if (and only if) it turns out we really have to.

NOTE: when I originally wrote this, I described it as "the main facade in Rx 7." That was a typo. I mean "main package in Rx 7." The whole point of this design option is that System.Reactive is not a facade.

[glopesdev]

For people not seeing the video and not reading the source code directly, is the "clever hack with reference assemblies" explained in writing somewhere in this discussion / issue?

If it is, it might be important to make it more salient, to help people investigate what assumptions does it depend on (i.e. what exactly makes it a "hack"?)

[idg10]

is the "clever hack with reference assemblies" explained in writing somewhere in this discussion / issue?

Currently it's only really explained in the video. So here's a short explanation.

The trick is to build the System.Reactive NuGet package in a way that includes reference assemblies as well as the assemblies to be used at runtime, and to include the UI-framework-specific types in the runtime assemblies, but to exclude them from the reference assemblies.

At compile time, the compiler uses the reference assemblies. So when you use a System.Reactive package built in this way, it will appear not to offer any WPF or Windows Forms support. (And this is what makes it possible for us to remove the Microsoft.Desktop.App framework reference without creating any problems.) However, when the application actually runs, the System.Reactive.dll it gets does still contain the old WPF and Windows Forms features.

Applications that were using Rx indirectly (via another library) in a way that relied on these UI framework features being present will be unaffected, because these features will indeed still be present at runtime. But applications that simply don't want any of these features now get to avoid the problems caused by an implicit dependency on the Microsoft.Desktop.App framework because this enables us to remove that.

The thing that makes this a "hack" is that reference assemblies weren't designed to solve this sort of problem. A reference assembly is supposed to capture the public API. If you build a reference assembly in the usual way (the C# compiler has built-in support for this), it ensures that the public API of the reference assembly precisely matches the public API of the real assembly. But my "hack" involves jumping through some hoops to produce a reference assembly that omits the UI-framework-specific features.

I have two concerns about this hack:

1. the build tools aren't designed to enable this sort of thing, and I'm worried that the 'creative' way I'm building it might fail at some point because I'm using the build tools in a way that is not supported
2. anything that makes the (reasonable) assumption that the public API of a reference assembly is always exactly the same as the public API of the corresponding real assembly is going to have its expectations confounded

I'm not too worried by 1 because there is a fallback: it's possible to craft reference assemblies by hand, and it's also possible to create tooling that does most of that work for you. (In fact the .NET runtime library source does that.)

But I am more worried about 2. Microsoft's own build tools make use of the reference assemblies at build time when NuGet packages supply them, so this works. But will this break tools like NCrunch, which run their own customized build processes? Does R# do its own custom build processes to support what it does, and will this break it? Might corporations have their own internal customized .NET build processes, and might those rely in subtle ways on the reference assembly precisely matching the public face of the corresponding runtime assembly?

[idg10]

...and if you think there are other options that are better that are not listed above, please upvote this one.

[glopesdev]

@idg10 for the sake of completeness, can you elaborate on why we couldn't design a strategy using the TypeForwardedToAttribute?

I am assuming this would work for all platform-specific scheduler types. Of course you cannot forward single extension methods, but I seem to recall these extensions are already under specific separate types such as ControlObservable, which could be themselves forwarded.

In this case, couldn't we just split these types away from the System.Reactive assembly, sprinkle a few of these attributes and be done with it?

This seems to be the recommended compatibility approach when splitting up assemblies and would keep binary compatibility for older projects.

I will be away from a keyboard until the end of the month so I cannot quickly run this alternative through the gauntlet myself just yet, but would be very interesting to understand whether / why it wouldn't work.

[idg10]

That's exactly how the facade strategies do work.

The problem is that by itself, it doesn't help you with the bloat problem. Imagine we move all the UI-framework-specific code out of System.Reactive and into new UI-framework-specific packages, and that for backwards compatibility, we replace all that code with TypeForwardedToAttribute. (For now we'll just ignore the problem that this attribute works at the type level, but some of the code in question consists of individual members present on types that also have non-framework-specific methods. That is a problem, but it turns out not to be the biggest one.)

For this to work, System.Reactive now needs references to all the UI-framework-specific packages, because the compiler's going to want to be able to see the target of the TypeForwardedToAttribute. The intent of TypeForwardedToAttribute is that it enables types to be relocated with no change in behaviour, so if you have a TypeForwardedToAttribute to a class that defines extension methods, those must continue to work. That means the compiler needs to look at each such type to find out whether it does in fact define extension methods.

And since all these types will be using UI framework types, those UI framework types also need to be accessible at compile time. So a dependency on System.Reactive now implies (for any app with a Windows-specific TFM) a dependency on Microsoft.Desktop.App, and we're back where we started. All that changes is we've made things more complex. We've not fixed anything.

[glopesdev]

Fair enough, I had forgotten the TypeForwardedToAttribute requires an actual Type handle rather than just a string.

Indeed, it seems one of the most common cases for type forwarding is splitting a monolithic assembly into "core" + "extensions".

The original Rx was already modular before, and because we did the full arc (modular > monolithic > modular) we cannot really use this, sadly.

[kmgallahan]

Do all RX extension methods cause the issue, or only the ones that involve UI-specific code?

If the latter, how many of those exist besides ObserveOn?

Technically, a 'clean break' could force a rename of said extension methods as another option - albeit rough and dirty...

[idg10]

Yes, @glopesdev is correct: when I talk about extension method issues in this context, it's only methods where we have UI-framework-specific overloads. (ObserveOn and SubscribeOn are the ones most commonly encountered. There are also platform-specific overloads of ToEventPattern and SelectMany, but those use types available to any Windows-specific TFM without requiring a desktop framework reference, so I don't believe those cause problems. And I think that's everything, although there isn't a straightforward way to find all these things, so it's possible I've missed one.)

Technically, a 'clean break' could force a rename of said extension methods as another option - albeit rough and dirty...

It's more 'break' than 'clean'. What happens to code that's already out there that was using this? What if an app author isn't even using Rx directly, but is using libraries that use it? If we make this change, they're going to get baffling missing method exceptions at runtime when upgrading Rx (which might happen without them even realising they've upgraded Rx, because maybe some other dependency upgraded it for them). And there will be nothing the app author can do to resolve this situation other than to stop using components that depend on Rx.

[kmgallahan]

@idg10 @glopesdev

Apologies guys, in my head what I meant was to 'force a rename in projects that want to use DisableTransitiveFrameworkReferences'.

There could exist both:

• ObserveOn
• ObserveOnThread / ObserveOnScheduler - whatever name makes the most sense, just examples
• SubsribeOn
• SubscribeOnThread / ObserveOnScheduler

Such that anyone using ObserveOn continues functioning as before. But when upgrading to the next major release of RX the new extension methods become available. They'd do the same thing, however, if you decide to change all of your usages you can then avoid the compiler errors and framework bloat via DisableTransitiveFrameworkReferences.

A diagnostic could be created that provides a warning - perhaps just limited to non-WPF/WinForms instances to indicate which extension should be used instead and the reasons for it.

For me at least, a find and replace on ".ObserveOn" to ".ObserveOnScheduler" would be pretty simple.

I do not know if 3rd party usage in referenced projects would still cause issues?

[idg10]

Are you proposing actually removing the UI-framework-specific overloads of ObserveOn?

If we do that, we break backwards compatibility: existing libraries that use these will, if used in an app that has upgraded to Rx 7, throw a MissingMethodException when they try to use the method. It means that an app can't necessarily just upgrade to Rx 7: it might require the components it depends on that use Rx to have been upgrade to Rx 7 too to avoid this problem.

Alternatively, if we retain these methods, adding the new ones doesn't help. The fact that an ObserveOn(Control) method exists means that any time your code calls obs.ObserveOn(something) the compiler will consider the ObserveOn(Control) overload as a possible candidate, and will require access to the Windows Forms assemblies to be able to determine that the overload is not applicable.

The critical point here is that the extension method problem doesn't affect code that actually wants to use the UI-framework-specific overloads. It affects code that's trying to use the non-UI-framework-specific overloads. If you set DisableTransitiveFrameworkReferences, the mere existence of the UI-specific overloads actually breaks code that's not trying to use them

[kmgallahan]

Are you proposing actually removing the UI-framework-specific overloads of ObserveOn?

No, there would exist:

System.Reactive.Linq.ObserveOn - all apps can keep calling it and functioning as normal, including those that aren't interested in DisableTransitiveFrameworkReferences

System.Reactive.For.WinUI.ObserveOnScheduler - UI framework specific packages contain this renamed version which can be called and does not result in a compiler error when using DisableTransitiveFrameworkReferences (replace WinUI with WinForms/WPF/UWP/whatever)

Alternatively, if we retain these methods, adding the new ones doesn't help. The fact that an ObserveOn(Control) method exists means that any time your code calls obs.ObserveOn(something) the compiler will consider the ObserveOn(Control) overload as a possible candidate

When I was testing this, the fact that the original ObserveOn existed wasn't the problem, it was only if my project tried calling it that resulted in the compiler errors. So is it not the case that as long as what you are compiling isn't directly trying to call the old method that everything should work? As in, when you call ObserveOnScheduler it is just going to use the extension as found in your UI framework specific package.

[idg10]

My findings have been that if the WPF/Windows Forms ObserveOn is visible to the compiler and you attempt to use one of the non-WPF/Windows Forms overloads, but your project does not have a reference to Microsoft.Desktop.App, then you will get a compiler error. (The Rx Gauntlet tests include repros for this.)

[idg10]

I'm tagging people who contributed to the original #2038 thread and who have not yet said anything here because I'm guessing at least some of you will have opinions, but might not have spotted this new discussion:

@anaisbetts @akarnokd @dameng324 @ChrisPulman @Trinitek @wmanning @frankhaugen @matt-goldman @JakenVeina @muhamedkarajic @MauNguyenVan @heronbpv

[akarnokd]

Hello. Sorry, I have nothing to add due to my limited understanding of such .NET infrastructure topics.

[JakenVeina]

If I had a vote, I think I'd have to put it on the "facade" approach. As a consumer, if I weren't already read in on this, and something weird were to happen in a project, that I needed to debug, I would only need standard knowledge of how package resolution in .NET works to figure out what's going on with the "facade" approach, while the "no-facade" approach requires some much more in-depth knowledge, and wouldn't be something people might have seen elsewhere. Plus, having issues that can only present at runtime is a big turn-off, for me.

Regarding the "try no-facade first" idea, I wouldn't really be against it, but given that I think "facade" is better, I'd probably say "don't over-complicate it".

I'll update if my opinion changes, after getting a chance to pull those previews and target them with something real.

[matt-goldman]

I'm still of the opinion that there's only so much you can do. I don't think you should be supporting backward compatibility indefinitely. Libraries change, dependencies change. Granted, the .NET way (and the broader Microsoft way) to an extent does historically tend toward non-breaking changes, but as much as people complain about the pain of XCode upgrades (and believe me, those complaints are more than justified), Apple certainly doesn't get held back supporting legacy dependencies.

I also still don't know the extent of the problem. I do realise it's not hypothetical, but do you feel you have a significant proportion of people who would be left with a type 2 scenario (as you described in that previous discussion)? Maybe it is important, but not having that visibility, if I had a vote, it would be for modernising, providing broad guidance where possible on upgrade paths, but ultimately introducing a breaking change. People can modernise their software, and if there are people out there with a critical dependency on the older versions, who can't upgrade (perhaps due to other external dependencies), or perhaps have conflicts between external dependencies as a result of this, then that falls more into the category of a business/organisational problem rather than a library maintainer’s responsibility.

Of course, it's all just my 2c. I'm far from an expert, and I'm definitely not invested to that extent. I think what you provide the community is incredible, and I think the effort that has gone into this is way beyond what a reasonable person could expect. I think you're well justified in introducing a breaking change. Especially considering that avoiding it is for edge cases.

[heronbpv]

Though I didn't voice anything explicitly in this thread, I did vote for the second option: keep system.reactive as the main package. Though the "hack" is perhaps fragile, it's for the best IMO.