same as my thought. totally agree with it.

I have an idea.

How about turningDispatcherScheduler into a delegator with no real implementation but forwarding into anIScheduler. The default behavior would to throwUnsupportedOperationException. A workingDispatcherScheduler in some other library & package name would then register itself with the Rx' version. Thus updatedUiLibA would simply use the new library DS indirectly. If theUiLibA was not updated, the App that uses it and the newer Rx would then just issue that registration.

UnlessUiLibA somehow usesnew DispatcherScheduler(...). Yeah, types would be broken.

I presume changing the signature tonew DispatcherScheduler(object dispatcher) wouldn't bind.

How widespread is the use ofDispatcherScheduler?

I don't know how we would obtain data that could answer that question. GitHub reports about 1900 files using it on GitHub, but I'm not sure that's a very illuminating answer to your question.

What are the chances of UiLibA never updating to look for DS somewhere else?

I've seen enough examples of projects stuck on some version of a component (for various reasons, including the component having essentially fallen out of support but there not being any realistic alternative) to have come to the view that it is problematic to hope that dependencies will simply always be updated. (And even when they are, it's often not on the schedule you'd want.)

In conclusion, my answer to this question is: I think it's probable that the changes are high enough to matter. (Rx is pretty widely used, so even if a small fraction of users were to be affected, that's a big impact. And I'm unconvinced it's going to be all that small a fraction.)

Rx has historically maintained pretty high standards of backwards compatibility. So for that reason we don't really know what the impact of a breaking change will be.

As for the clean start, there would be a lot of clashes due to the use of extension methods, right?

That is a very good point. I had been thinking that because most of what Rx does is most naturally used as implementation detail—the number of types that it defines that you would likely make part of your own class's public API is fairly small, and the two most important types,IObservable<T> andIObserver<T> are defined in the runtime libraries.

But I hadn't thought about what happens when some random dependency deep in your tree brings in "the other Rx". That would be a major problem.

So that rather suggests that a complete split would be a mistake, and that we'd want to unify to exactly one version of Rx.

How about turningDispatcherScheduler into a delegator with no real implementation

The problem with that is that its public-facing API includes types defined by WPF. So even with a hollow shell, you still end up with a dependency on WPF.

But I hadn't thought about what happens when some random dependency deep in your tree brings in "the other Rx". That would be a major problem.

@idg10 I can confirm this is a huge problem, I tried such a workaround for moving away from the old v2.2.5 binaries and found that there was no way to run away from it, since any little package left unchanged would break it back again. The only alternative was to use a different TFM as I suggested below.

So that rather suggests that a complete split would be a mistake, and that we'd want to unify to exactly one version of Rx.

Completely agree, I think it would not be enough to just fork the package, you would need to fork the namespace itself. That is exactly what I think would create massive confusion within the community.

So even with a hollow shell, you still end up with a dependency on WPF.

We need to cut these out, the current architecture is completely untenable. It is very sad that it got to this state, but I don't think we need to give up on change.@akarnokd see my proposal below, I would be curious to hear your feedback.

And I know I'd rather see a consolidation of community contributions to the official repo to help drive the project forward, rather than seeing it fracture and that effort become diluted...

On the contrary, it's at the heart of the proposed change, unfortunately.

Sorry, you're right - what I meant to say is, the problem of updating dependency chains is not unique to this library, or to this change.

@idg10

Even "type 2" changes as described in my earlier post? (That is, the kind where application authors simply can't fix the problem, except by stopping using whichever components are putting them in this situation.)

If I were in this scenario, yes, I wouldn't hold it againstSystem.Reactive for introducing a Type 2 scenario, if it means I'm no longer forced to pull in other large dependencies, I may not need. I actuallyam in a similar situation at work right now, We're gradually refactoring out our dependency on a third party library that's holding us back from updates to quite a few other libraries, and most-significantly, .NET Framework itself. I don't hold it against the folks that created .NET Core and .NET 5+ that this other third-party library isn't updating to match. We're just gradually removing our dependence on this library.

Also, to be clear, I didn't mean to imply that these changes are not breaking, by putting "breaking changes" in quotes. I'm honestly not sure why I did.

1. do you think it's necessary to break backwards compatibility in order to get a "sane dependency tree"?

My understanding was that all the proposed solutions would be breaking backwards compatibility insome way. Your illustration with regard to type-forwarders seems to be what I was missing. I'm actually not familiar with type forwarders, so that was very helpful. This setup does need to come with some clear documentation, for newcomers to the ecosystem, then, because itis introducing more complexity to developers and the dependency-resolution process.

2. do you think that there's some specific way of breaking backwards compatibility that guarantees that we end up in a better place?

So far, my favorite idea was (coincidentally, I promise) the one I suggestedhere, assuming it works. It also looks like you mentioned the same ideahere. I like it because it follows a "normal" process of introducing breaking changes pretty closely: Changes are presented directly to developers, as they write code, while also providing lead time to address them.

So even if you don't care about back-compat scenarios, it doesn't looks like we have very much to gain here from a breaking change.

With everything you've presented, I think this is a fair assessment.

@JakenVeina What I don't like about the current proposal is there is no plan to ever phase out the bloated packages and therefore no incentive for current library maintainers to stop developing the way they have so far. Will we continue to maintain type forwarders for UI schedulers indefinitely? Will we continue to maintainSystem.Reactive.Core undeprecated indefinitely? Note that deprecating a package on NuGet.org comes with expectations that the package will stop being updated, so we would have to stop shipping releases ofSystem.Reactive forever.

@idg10 has mentioned elsewhere that because Rx uses theSystem namespace it somehow must hold itself to a high regard in terms of backwards compatibility. I think this is wrong-headed because that is not how even .NET itself is behaving at the moment. This was true of .NET framework, but you only need to have a cursory look at breaking changes introduced since the release of .NET 6:

• https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/7.0/system-drawing
• https://learn.microsoft.com/en-us/dotnet/core/compatibility/8.0
• https://learn.microsoft.com/en-us/dotnet/core/compatibility/7.0
• https://learn.microsoft.com/en-us/dotnet/core/compatibility/6.0

The very fact that we have these long lists ofbinary breaking changes should be a big clue about how Microsoft is dealing with evolving their ecosystem. Even just the first item on this list already raised some huge backlash from the community and is holding back and causing refactoring ofentire projects across the .NET ecosystem including core plotting libraries. And yet here we are with .NET 8 and the world hasn't ended.

Microsoft have repeated the mantra time and again that theywill break things for the sake of sanity, and that consumers are given 3 years to adapt between LTS releases. Right now I am assuming there isno promise of stable binary compatibility across .NET TFMs so even ifSystem.Reactive stays binary stable your app can still break.

I don't understand why given this we are assuming thatSystem.Reactive needs to somehow hold itself to a higher standard than the core framework itself.

There is a namespace calledSystem.Reactive, a package calledSystem.Reactive, and already four other packages that do type forwarding. Do we really need to create confusion by adding a 5th package that has nothing to do with this namespace that somehow is not even a type forwarder itself?

I don't buy the argument of counting nodes in a "dependency tree" as a measure of complexity. Humans often care more about names than they care about numbers. My definition of "sanity" is not just that we have one package, it's that the root of the namespaceSystem.Reactive shouldnot be in a package calledSystem.Reactive.Base.

I don't understand why we are all giving up when the tools are there to deal this gracefully, with respect for both the existing communityand new developers. As it stands, I cannot say I am looking forward to the day where Rx 101 starts with "first install theSystem.Reactive.Base package (DO NOT INSTALL THESystem.Reactive PACKAGE)"...

there is no plan to ever phase out the bloated packages and therefore no incentive for current library maintainers to stop developing the way they have so far. Will we continue to maintain type forwarders for UI schedulers indefinitely?

Were you aware that we Rx has already been doing this for about 8 years?

Do you know the names of the existing type forwarders that Rx has been maintaining for all that time? If not, can you honestly say they are a problem? And even if you do know what they are, do you believe their continued existing is causing a problem? I've not been aware of their being a problem, but perhaps there's something I don't know.

Would it be nice to get rid of them? Sure. It's one less moving part. But as far as I know they're not really a big deal, and I have no way of knowing what the impact would be of dropping them.

Re: .NET and breaking changes

I've not been through every one of the changes in the lists you linked to, but I did systematically go through quite a lot of them to see if I was missing something. I have a few observations.

First of all, the .NET team evidently has their "breaking change" detector set to a much more sensitive level than the Rx project does, figuratively speaking. A great many of the things they label as "binary breaking changes" are things we probably wouldn't think of as breaking changes in Rx, because they won't break most people in most circumstances. (That makes these kinds of changes very, very different from something as radical as removing something from a public-facing API without first going through some fair-warning period ofObsolete annotation.)

E.g., look at the various "binary breaking changes" toFileStream. I followed some of that work while it was in progress. All those changes were agonised over in multiple review meetings with many contributors where a huge amount of effort was put into working out how to minimize the possible impact and to be certain that the pay-off was large. The goal was that it should effectively be binary-compatible in practice. And they also provided a mode where you could tell it to use the old behaviour just in case the new behaviour caused you a problem. (Some of the changes in that list of "breaking changes" relate to the fact that the fallback mode is now being phased out after several years of customer using demonstrating that the changes were indeed binary-compatible in practice for almost everyone.)

The effect is that for the overwhelming majority of consumers, thoseFileStream changes won't break any existing code. It is nonetheless labelled as a set of binary breaking changes according to those docs. So, far from being an example of Microsoft's readiness to impose breaking changes, I'd say that's actually an excellent example of the lengths they go to in order to preserve backwards compatibility even when they make what is, according to the very exactly criteria they set themselves, a breaking change.

Quite a few more of these changes look like various stages of multi-year moves to make things obsolete. (Quite a few relate to the security-driven decision to gradually stop people using CLR serialization.)

As far as I can tell, most of the things labelled as binary breaking changes there don't come close to the destructive impact of the kinds of changes we're discussing here.

Another observation is that a lot of the changes seem to relate to evolution of application frameworks (e.g., ASP.NET Core or Windows Forms). I think there's a major qualitative difference between evolving the design of a framework, and introducing a breaking change to something like LINQ to Objects. Chosing a framework is a top-down decision not taken lightly. The use of a library feature is something other libraries will often impose on you. This makes them quite different things. And I'd ask you: which do you think Rx is more like? ASP.NET Core or LINQ to Objects? I think it's more like the latter. Rx is core library functionality, not a framework, and although there are some library types in that list of changes, the ones I looked at were all more like theFileStream changes: labelled as binary breaking changes, but with every effort made to ensure that they won't actually break most consumers in practice.

I don't understand why given this we are assuming that System.Reactive needs to somehow hold itself to a higher standard than the core framework itself.

We aren't.

We hold ourselves to a much lower standard.

We have to, for the simple reason that we just don't have the resources to take the care and attention that the .NET team does when making changes of the kind they did to improveFileStream performance.

I don't believe I ever said we had to exceed or even equal the standards set by the frameworks (standards which I think you have unfairly discounted in your argument). What Idid say is that because we're in theSystem namespace and because of what we've done in the past, people will expect:

higher standards of backwards compatibility than with the average NuGet package.

I did not say we're going to go to the same lengths as the .NET team. Just that we should do better than average.

As those links you've posted show, the .NET team will label some things as a "binary breaking change" if it's merely an observable change in behaviour. That's actually a much higher standard than the one I'm aspiring to in this discussion. By that standard,#1968 and#1882 are both binary breaking changes, but I'm OK with that. Those are on the "internal implementation details ofFileStream are now slightly different" level.

I think it's really important to recognize that removing things from the public API ofSystem.Reactive without having first gone through any phase ofObsolete is a huge act of violence compared to the vast majority of the changes in those lists you link to. Compare it to, say,https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/7.0/filestream-compat-switch and it seems absurd to put these in the same category.

It is, in my view, a mistake to consider all "binary breaking changes" as being essentially the same sort of thing. I therefore do not think the fact that .NET itself has made a lot of binary breaking changes gives Rx an excuse to do things that we know will definitely break things for our users.

In summary, I've tried to clarify that my view on the need for backwards compatibility is not quite as extreme as you had thought. I have always been aware that we're not on the same level as the .NET team, but stand by my view that we need to be better than average.

the net6.0 target does not in fact bundle WPF and Windows Forms schedulers. Those are only in the net472 and net6.0-windows10.0.19041 targets. The existing net6.0 target already looks exactly like you are proposing.

So existing .NET 6.0 apps would get the same behaviour as today. .NET 8.0 applications would find that types such as [System.Reactive]::ControlDispatcher no longer exist, which I believe is what you intend.

@idg10 that is great news and definitely sounds like it would do exactly what I was hoping.

But my example doesn't have them using a legacy package. The app in that example uses the current version of Rx. Rx 6.0 is not legacy. It's the only choice you have today if you want to use Rx in green field development of a .NET 8.0 app.

I understand this concern, but this is actually then a different question: "is .NET 8.0 the right TFM to introduce this change?".

For that particular question, I am willing to concede that maybe you are right and now is not the right time, since we were not ready in time for the release which is now passed, people can use it and they will build up legacy. But we can still use the exact same approach for .NET 9.0.

In the meantime you can still announce the intention to remove platform-specific TFMs fromSystem.Reactive for .NET 9.0 and consider introducing some preview packages like@matt-goldman suggested.

As the main maintainer you would ultimately make that call, but it looks to me now that this strategy is the strongest option, especially given everything you outlined above.

To summarise and check if I understand correctly, the logic if we wanted to do this today would be to release Rx v7 with the following TFMs:

• net472
• net6.0
• net6.0-windows (with platform schedulers)
• net8.0
• net8.0-windows (without platform schedulers)

The last TFM would be literally just a replica of net8.0 but is actually crucial if I understand unification correctly.

You need it since applications targeting net8.0-windows might fallback to net6.0-windows if the newer target is not there and thus retain the legacy.

I hope that in later releases, e.g. .NET 9.0 we would be able to drop the windows TFMs entirely since any fallbacks would get the same assembly, but I don't know the details.

Either way this seems workable unless I am missing something?

but this is actually then a different question: "is .NET 8.0 the right TFM to introduce this change?".

Is there any TFM in which this change wouldn't cause all these same problems?

I think the right TFM to fix the underlying problem would have been .NET 6.0 because this has already been causing pain for some time, and has caused at least one major project to abandon Rx.NET. The idea of deferring it for another version or two is not one I much like, so I think there would need to be a pretty strong upside.

So let's think the scenario through to see what the upside of deferring this fix might be. Suppose today we markControlDispatcher,CoreDispatcher, and the other problematic types as deprecated. We ship Rx 7.0 in that state, and the basic problems persists, but by having signalled that these types are deprecated, we have the way for some future version in which those types go away after however long we think is the minimum acceptable time between deprecation and outright removal. In the meantime, we ship equivalent functionality in new types in separate components, so people have a way to move forward.

The upside, I believe, is that at some point in the future we get to ship theSystem.Reactive that we always should have shipped (i.e. one that has no UI-framework-specific types, and no OS-specific TFMs).

That's undoubtedly a good upside. But the question then is: how long is long enough?

Elsewhere you've raised issues dating back to Rx 2.2.5, a version that shipped about 9 years ago. If that version is still relevant to this discussion today, what's the earliest you think we could actually release a version ofSystem.Reactive in which we had removed these types?

That's undoubtedly a good upside. But the question then is: how long is long enough?

@idg10 To answer this question I feel I need to understand and qualify a bit better the nature of a "type 2" change. Specifically, I need to understand whether we agree on the "target audience" for a "type 2" change.

I only see a way out if we are willing to accept first that the target audience for "type 2" changes are maintainers ofexisting applications. If this is the case, then I submit that the right TFM to introduce this fix would be any TFM that is not released right now, since by definition there can't be maintainers ofexisting applications on TFMs that do not exist yet.

If on the other hand the target audience for "type 2" changes are all current and future developers of both existing and yet to exist applications and TFMs, then I agree with you there seems to be no hope for a clean break onSystem.Reactive. Below I will talk only of my "hopeful" scenario.

.NET 8.0 is now released, so let us callnet8.0 the existing TFM andnet9.0 the hypothetical future TFM. Imagine a developer of an existing .NET 8 app targetingnet8.0-windows10.0.19041 that started using Rx this month and is pulling in a bunch of dependencies using Rx v6.

Let us say Rx v7 provides anet8.0-windows10.0.19041 with UI schedulers for WinForms and WPF, etc, and that this will be the last TFM that Rx targets with thewindows suffix, i.e. we never release anet9.0-windows10.0.19041 at all and we release Rx v8 synchronized with .NET 9.0 next year with only anet9.0 TFM (plus the legacy ones, includingnet8.0-windows10.0.19041). What will happen to both our legacy maintainer and developer of a brand new app?

First, I think we can agree that as long as the legacy maintainer does not change his TFM, nothing will break.

What I was still curious about is whether we could really free developers of new apps entirely from the "curse of schedulers" by dropping the platform specific TFMs. Can we really say for sure that if a new developer targetsnet9.0-windows10.0.19041 they won't pullnet8.0-windows10.0.19041 inadvertently through the compatibility unification mechanism, even though there is anet9.0 only target?

To answer this question I made a mock project implementing this idea with .NET 6 and .NET 7 (just because I have them handy). Here are the relevant bits:

Mock System.Reactive v7 targets

<TargetFrameworks>net6.0;net6.0-windows10.0.19041;net7.0</TargetFrameworks>

As a control, I introduced an API surface exclusively for thenet6.0 target and another fornet7.0 targets so I could check which ones would be available at runtime. I also created a test dependency that targets only specificallynet6.0-windows10.0.19041 to see how indirect dependencies would be resolved.

namespaceSystem.Reactive{#ifNET6_0publicclassDeprecatedApi{}#endif#ifNET7_0_OR_GREATERpublicclassShinyNewApi{}#endif}

I started out with a "legacy app" targetingnet6.0-windows10.0.19041 and verified that obviously it cannot accessShinyNewApi since it only exists on .NET 7.0. I then modified it so that it targetsnet7.0-windows10.0.19041 to check whetherShinyNewApi (which is exclusive tonet7.0) gets pulled or whether dependency resolution would somehow prefer thenet6.0-windows10.0.19041 target because of platform specificity.

As I hoped, thenet7.0 TFM was preferred andShinyNewApi is available. This is good since it is at least confirmation that a clean break for new developers targeting directly Rx vNext on the next TFM would free them from the "curse of schedulers". What about indirect dependencies? Unfortunately here the story gets complicated as probably@idg10 was already aware and trying to explain, but it wasn't entirely clear to me.

First of all, the main thing to notice is that the most specific TFM (in this casenet7.0) is always preferred. This is actually the version of Rx that gets pulled so the clean break is enforced and cannot be overridden by any indirect dependency. This isgood news. Thebad news is that the indirect dependency that targets the older TFM (net6.0-windows10.0.19041) is still allowed to be pulled into the main app, even though it's indirect dependency is resolved with a package that does not support the stated TFM. This is unfortunate, and I think potentially even an issue with NuGet dependency resolution, but ultimately let's accept it and look at it one more time from the point of view of our stated "target audience".

• "legacy maintainer": if this scenario happens, it means the maintainermust have tried to update its TFM. This for me is anacceptable breaking change. It's not a type 2 change from my perspective since the developer has stepped out of our target audience by moving outside the scope of our backwards-compatible TFMs. It is always a deliberate choice to update the TFM (not simply an accident of upgrading the package).

• "new developer": if this scenario happens, it means the new developer pulled in a legacy dependency. This is unfortunate, but he will likely pick up the problem before the app is out so legacy is not allowed to accumulate. This for me is also an acceptable breaking change since as stated above the new developer is not our target audience for back-compatible surface API under the working hypothesis.

I think this is honestly the best scenario I can conceive of for a clean break that preservesSystem.Reactive as the base package. If the assumptions I held about the target audience are incorrect and undesirable for the community, then I agree I cannot see any other way.

That's undoubtedly a good upside. But the question then is: how long is long enough?

As a rule of thumb I would use Microsoft's own end-of-support dates as deprecation targets, so if we introduce the break in .NET 9, the back-compatible TFMs would be around until .NET 8 end-of-support, which is currently stated as November 10, 2026, so 3 years from now.

Elsewhere you've raised issues dating back to Rx 2.2.5, a version that shipped about 9 years ago. If that version is still relevant to this discussion today, what's the earliest you think we could actually release a version of System.Reactive in which we had removed these types?

If anything, I think our story is an argument for why these kind of problems are not the end of the road that they are often made out to be. Our application is still going strong and we have a roadmap for changing into modern .NET.

Rx has historically maintained pretty high standards of backwards compatibility.

Our story shows this to be untrue, since we were effectively split up from the entire Rx community without even the possibility of using type forwarders (because of the arbitrary strong name change). In fact, if anything, the strong name key change showed that Microsoft does not consider the use of theSystem namespace by itself to be worthy of signing an assembly with its public strong name key. Not sure what that means in terms of expectations and aspirations for Rx.NET.

In the end what I believe can save us is the fact that the library is open-source and evolving, and not any kind of implicit contract on the immutability of API surface areas. For more examples see also#2038 (reply in thread).

I need to understand whether we agree on the "target audience" for a "type 2" change.

I only see a way out if we are willing to accept first that the target audience for "type 2" changes are maintainers of existing applications.

Sadly, This isn't necessarily the case. Someone could start writing an application later this year (let's say March 2024) targeting .NET 6.0 (and yes, I know, but people do this, sometimes for unavoidable reasons—Azure functions .NET 8.0 support has some limitations right now for example) and then take a dependency on some other component, let's call itProblemSoft.Lib that has a reference to Rx 5.0, and which doesn't use any of Rx's UI-specific features. Then in September 2024, they add another package,FlashyLib that also has a reference to Rx 5.0 but whichdoes use the WPF-specific features. In October 2024, a newProblemSoft.Lib package ships with a feature that they need. As it happens, it has two targets:net6.0 andnet8.0. Thenet6.0 version continues to depend on Rx 5.0, but thenet8.0 version actually depends on Rx 7.0, but this doesn't affect the app because it's using .NET 6.0, so they are still using Rx 5.0 indirectly.

Let's say we released Rx 7 in February 2024. This doesn't affect the application authors at the time, because their application won't exist for another six months. It also doesn't affect them when they start writing it in August, because they're on Rx 5. In November 2024, .NET 9 ships. Also, .NET 6.0 goes out of support, so they try to upgrade to .NET 9.

Now let's look at how we might have made a change in Rx 7 in March 2024 some 5 months before they started work on their app in August 2024 is going to cause them to become victims of a type 2 problem. It's going to stop them from upgrading to .NET 9, or even to .NET 8.

Suppose we did the thing we really wish we could just go ahead and do: remove all the UI-framework-specific stuff fromSystem.Reactive. And we did that in February 2024 (in this hypothetical.)

The app authors in this example (who, don't forget, started work later, in August 2024) find themselves in a type 2 situation when they try to upgrade to .NET 9.0. Just to remind you of my definition:

type 2: we put the app authors in a position where it's not possible for them to get everything working again

Because they upgraded to .NET 9.0, they're now getting thenet8.0 target ofProblemSoft.Lib, which wants Rx 7. The build system will upgrade their app to that, and because package versions unify, that means thatFlashyLib also gets upgraded to Rx 7.

ButFlashyLib now won't work, because it was using the WPF functionality. And in this hypothetical scenario, we removed that in Rx 7. So there now is no version of Rx that works for them. Rx 5 and Rx 6 are older than what thenet8.0 target ofProblemSoft.Lib requires, so if that tries to use new members defined in that version we'll getMissingMethodException or similar at runtime. But if we use Rx 7,FlashyLib will break because it relies on Rx's WPF functionality, which (in this hypothetical) we removed in Rx 7.

They can't use either .NET 9.0 or .NET 8.0. .NET 7.0 will already be out of support at this point. Staying on .NET 6.0 will avoid these problems, but that also just went out of support, so they can't do that either. There is nothing they can do to resolve this problem.

So that demonstrates that it would be possible for us to do something to Rx in February 2024 which will cause an application to that didn't even exist until August 2024 to have a "type 2" problem in November 2024.

So although that may be a slightly convoluted example, it's an existence proof that your assumption is not guaranteed to be correct. We therefore can't in fact say that victims (a more accurate description than "target audience", I think) of a "type 2 change" can only be maintainers of existing applications. We could do things today that create a time bomb where application development started in the future is initially OK, but runs into trouble later on because of something we already did before they got started.

If this is the case, then I submit that the right TFM to introduce this fix would be any TFM that is not released right now, since by definition there can't be maintainers of existing applications on TFMs that do not exist yet.

Notice that in the scenario I just described, the "type 2" problem becomes apparent at the point where the application developer attempts to upgrade to a TFM that didn't exist at the start of the scenario.

You might be inclined to dismiss this because it's weird and contrived. All I can say is that I've encountered weirder situations than this helping people resolve problems in real applications.

The problems are always lurking somewhere deep in the dependency tree. This is the main reason I am very reluctant to remove things from the API of existing components. I've been on the receiving end of decisions to do that in the past, and it's a world of pain.

Let us say Rx v7 provides a net8.0-windows10.0.19041 with UI schedulers for WinForms and WPF, etc, and that this will be the last TFM that Rx targets with the windows suffix, i.e. we never release a net9.0-windows10.0.19041 at all and we release Rx v8 synchronized with .NET 9.0 next year with only a net9.0 TFM (plus the legacy ones, including net8.0-windows10.0.19041). What will happen to both our legacy maintainer and developer of a brand new app?

OK, so let's tweak the versions and timing of my example to align with your example:

• Rx v7 ships with anet8.0-windows10.0.19041 target including UI support in, let's say February 2024, with the UI-specific stuff all marked as deprecated
• DoomedApp starts work on August 2024 using:
  • ProblemSoft.Lib v1.0 which depends on Rx 5.0
  • FlashyLib v1.0 which depends on Rx 5.0 and uses the Rx WPF features
• .NET 9.0 ships in November 2024 (DoomedApp does not upgrade immediately)
• Rx v8 ships in December 2024 withnet9.0 support and no-windows version and no WPF support
• Jan 2025ProblemSoft.Lib release v2.0 with anet8.0 target depending on Rx 5.0, and anet9.0 target depending on Rx v8
• Feb 2025DoomedApp still on .NET 8.0 upgrades toProblemSoft.Lib v2.0 because they need one of the new features it offers
• .NET 10.0 released in November 2025
• In June 2026DoomedApp authors realise .NET 8.0 will soon be out of support, so they try to upgrade to .NET 10.0

We now have a "type 2" problem. When they upgrade to .NET 10.0,ProblemSoft.Lib v2.0 (which they've happily been using without problems for over a year) will now force them onto Rx v8. But now,FlashyLib v1.0 (which they've happily been using without problems for almost 2 years) no longer works because it was dependent on the Rx WPF features, which are not present in Rx v8. They can't downgradeProblemSoftLib v2.0 because they needed the new feature.

It's June 2026, so they do have the option to switch back to .NET 8.0. So it's not strictly a "type 2" problem yet. But it will have become one in November when .NET 8.0 support ends.

So in this scenario, a decision taken today, followed up by the removal of a public API in December 2024 causes a type 2 problem in November 2026.

First, I think we can agree that as long as the legacy maintainer does not change his TFM, nothing will break.

If the legacy maintainers do not change the TFM, they will inevitably enter a state where they are running on an unsupported runtime. I would describe this as broken.

So no, I do not agree that nothing will break. Their application will become a security liability in November 2026 if they do not change their TFM before then.

The ultra-short support lifecycles of .NET today make this a much more difficult problem.

If .NET LTS versions had similar support lifetimes as Windows, then I'd totally accept your argument. They could leave their TFM unchanged. .NET 8.0 would remain in support for a decade. That's good enough. But unfortunately the "Long" in LTS is not very long.

It is always a deliberate choice to update the TFM

I think this is the core of where we disagree.

It's always deliberate. It's not always a choice. If you're on a runtime that's about to go of support, it takes a deliberate action to upgrade to a newer runtime. You have no choice but to take that deliberate action.

For all that I disagree with the details, I think it may be that the resolution is just to have longer timescales. So mark the types as deprecated in the next version. Then after, say, 3 years we start using NuGet package deprecation—mark the last NuGetSystem.Reactive drop that provided non-deprecated UI-specific features as obsolete, in order to push people into using versions of the library that will alert them to this looming problem. (E.g., in my scenario, the hope would be that this would be a wake up call for the authors ofFlashyLib.) Ideally this would also give the authors ofDoomedApp a heads up, although since the actual use of the problematic UI-specific features is in someone else's library I don't know if we could do that. Maybe we could somehow add stuff to the package'sbuild folder that says "Hmm, it looks like you're using libraries might be using features that are going away" so thatDoomedApp can go talk to theFlashyLib authors, or maybe find a replacement before it becomes urgent.) And then maybe another 3 years after that we can remove it.

So by about 2030 we might finally have recovered from a decision that looked like a good idea in 2018.

Perhaps the best way to start from a new base is to create a new Legacy branch within this Repository and make that the on-going patch and support base for the current state of affairs.
We can then safely clean house on this branch and take Reactive into a new direction providing a proper segmented code base.

I may have misunderstood, but are you proposing what amounts to a fork? To use the "new Rx" you would take a dependency onSystem.Reactive.Main?

This means it's possible for a single application to end up with a reference to both "old Rx" (what we have today) and "new Rx".

We were initially contemplating such a "clean start" approach, until@akarnokd pointed out the horrific flaw in this approach in his comment at#2038 (comment)

The critical part is this: if you end up with dependencies on both old Rx and new Rx, "whoseSelect() will be applied onIObservable? You could add one new package reference which, unbeknownst to you, had an indirect dependency on old Rx, and all of a sudden, simple code like this:

myObservable.Where(x=>x>2)

fails to compile because the C# compiler can see two extension methods forIObservable<T> calledWhere (both in the same namespace), one from old Rx, and one from new Rx.

This has led me to the view that whatever solution we choose, if you end up depending on both Rx 6 and Rx 7, theObservable type has to unify to a single type. If you bifurcate by moving existing types into new assemblies without making the v7System.Reactive forward those types to those new assemblies, you end up with this problem.

Or were you envisaging thatSystem.Reactive would indeed become a legacy facade of type forwarders in your new design?

System.Reactive would and should live on as a facade either as a codeless container with only shims for the legacy packages, or perhaps in addition as the host for a builder mechanism allowing the selection of function implementations for the various platforms. Quite correctly we can't remove this package or the inclusion of an older code base with an inclusion of <= Rx V6 will fail.

This does indeed make sense.

The only reason we hadn't initially suggested this was that it meansSystem.Reactive would need to continue to have WPF and Windows Forms dependencies until such time as we can remove the obsolete members. And since nobody seemed to have found a workaround for the problems this was causing, this did not seem like it would solve the major problems this was causing quickly enough. I think .NET 10.0 might be a little early to be removing members—that's a fairly aggressive schedule from getting from "obsolete" to "gone". So in practice we might be stuck with the current problems for many more years.

However, now that we seem to have found a workaround, there's a lot less pressure to make changes quickly.

As a result, this approach now looks like it's probably the most promising. It enables us to retain the current package structure. It provides people with a warning of the problems. And it provides a clear path for us to get to the ideal destination state in which UI-specific features are off in separate components.

For me there are still some questions around exactly how we do it. One option is to haveSystem.Reactive temporarily be a facade: the UI-specific stuff could be obsoleted and everything else could be moved into, say,System.Reactive.Main or whatever we chose to call it, andSystem.Reactive could type forward all the non-UI-specific stuff to that. The advantage of this is that it means there is a way for people to use Rx in a way that doesn't require the workaround without waiting for it all to be resolved properly.

However, I'm not sure if that's worth the complexity. It really depends on how well the workaround works out for people in practice.

@anaisbetts I am also not a fan of DLL proliferation, in fact the opposite. However I don't think the problem being discussed here is just a concern with disk space. For example, I have outlined in#1847 a collection of issues that are currently caused by the current approach of having a single "mono-package" forSystem.Reactive.

The problem is that the mono-package approach can change the API surface of Rx depending on which platform you target, e.g. by assuming the consumer wants to use WinForms and UWP just because the runtime architecture of the project happens to benet6.0-windows10.0.17763.0. I think this is confusing in general because UI frameworks will continue to come and go, and most Rx operators exceptObserveOn andSubscribeOn are completely agnostic to this. Apparently several others are facing similar problems, judging by the list of open issues related to managing project dependency trees where Rx is involved.

Can you elaborate a little on why you think splitting just these platform-specific schedulers would be so much worse than the current situation? I actually would like to hear what exactly is the pain from the other side, since so far we have heard here mostly an agreement that the current state of the package is untenable.

Pulling in massive WPF dependencies when you don't need it isn't just "annoying" and doesn't just "suck", it's a deal-breaker for most large-scale consumers. Avalonia determined it was less painful to removeSystem.Reactive entirely, and re-implement all the operators they were using as internal helpers. That's a huge clue that, yes, consumers are indeed worried about disk space here in 2023.

At the end of the day, final-product complexityshould carry far more weight in decision-making than design-time complexity. Having components split across multiple DLLs is not a significant barrier to entry in .NET land, not since .NET Core. The debate here is which approach offers the minimum change in design-time complexity.

With alot of IoT devices they don't have much disk space or memory, they are designed as low cost single purpose devices and are just responsible for sending a small amount of data at high data rates, they need a tidy and efficient installation for the devices to run efficiently.
So yes the size is important in some cases, admittedly not every case has this limited resource issue.
Using Rx on these type of devices is an excellent option, but if the application is too large then more expensive hardware is required pricing the option out of the market.

Web Servers, Desktop PCs, and Mobile devices generally don't have such an issue in this modern world.

I don't believe we are talking about changing namespaces, or function names, but taking the current 'Reactive Onion' as I have described it (layer upon layer of interlocked functionality) that Rx has become and flattening it out a little into specific concerns allowing for future flexibility and adaptability to cater for the needs of the various use cases Rx has.

I'd also say that I believe a core "growth & purpose" use case for Rx is IoT, and the new version of the Introduction to Rx book has more of a focus on IoT / event processing, than the traditional WinForms / WPF / UI examples - as these are mainly catered for by the ReactiveUI stack. Rx running in WASM (https://youtu.be/KzQ_Whn6oBA?t=27298) shows what a possible future might look like.

I feel that there's also a long shadow of the bad old days of figuring out which of a zillion combination of DLLs are needed for your scenario, which is not really what any version of this proposal is talking about.

The "decomposition" proposal is essentially a single base assembly that everyone could depend on (e.g. IOT/server side apps as well as UI apps) with an opt-in choice of UI tiers to include if you happen to be building a UI application on one framework or another (with 3rd parties also providing support for their UI frameworks).

And the "backwards compatibility" proposal is trying to achieve the situation where there is a legacy package that aggregated everything together so existing consumers would have the "full fat" experience they have today, up and down the dependency tree.

That legacy is inevitably going to cause anxiety and that's why this thread is so important - there are lots of competing perspectives that have to be balanced out.

In that regard, I'd make special note of the legacy support for UWP consumers; we know there are a lot out there in the real world, even as UWP is being deprecated by MS. The approach to phasing out System.Reactive support is another important consideration.

is there a possibility to improve the dependency resolution that ends up bringing the WPF/Winforms dlls, in such a way that doesn't happen to non-WPF/Winforms applications?

I believe that you described pretty much the problem that is at the root of what is being discussed here. Unfortunately the answer to this question seems to be "no", at least without introducing breaking changes to the package.

This prompted me to review in depth the full chain of causality that leads to these DLLs being present. (I've gone and found the relevant source code in NuGet and the .NET SDK.) And as a result of this, I've made a discovery.

It appears that in .NET SDK 8.0.100 at least (and possibly older SDKs—I've not yet tested this on older ones) a workaround is available that might enable us to move forward in a different way.

It turns out that if you have an application that is using Rx.NET 6.0.0, and is afflicted by the "complete copy of WPF and Windows Forms gets included" problem, you can work around it by adding this to your application's project file:

  <PropertyGroup>    <DisableTransitiveFrameworkReferences>true</DisableTransitiveFrameworkReferences>  </PropertyGroup>

This prevents the unwanted framework assemblies from being copied into your output.

You still end up building against the.net6.0-windows10.0.19401 target of Rx.NET, but if you never actually use its WPF or Windows Forms functionality, then you won't encounter a problem. (And if you do use that functionality, well that means you do actually need to include them in a self-contained deployment.)

The only fly in the ointment here is that I can't see a way to include just the Windows Forms but not the WPF components. I tried this:

  <PropertyGroup>    <DisableTransitiveFrameworkReferences>true</DisableTransitiveFrameworkReferences>    <UseWindowsForms>true</UseWindowsForms>    <UseWPF>false</UseWPF>  </PropertyGroup>

but for some reason this ends up giving you all the WPF components anyway. So if you're building self-contained Windows Forms apps, this is suboptimal. But it does at least appear to offer a fix for the problem when using Avalonia.

If this proves to be an acceptable workaround, this then gives us a (multi-year) path for finally getting to the place where we want to be:

• Rx.NET 6 (today): a workaround turns out to be available
• Rx.NET 7: signal where we're going
  • Continue to offer a-windows10.0.19401 target inSystem.Reactive
  • MarkControlScheduler,DispatcherScheduler,ControlObservable andDispatcherObservable as[Obsolete]
  • Introduce new UI-framework specific NuGet packages providing identical functionality (but we'd need new names)
• Rx.NET v.nextⁿ (however many years hence is deemed "long enough"): remove the-windows10.0.19401 target entirely fromSystem.Reactive (the desired end state)

This would meet the preference that I (and@glopesdev ) have for keepingSystem.Reactive as the entry point for Rx.NET. It provides a path for getting all UI-framework-specific functionality out into UI-framework-specific packages, with an eventual end state ofSystem.Reactive no longer needing to offer a-windows target.

The absolutely critical enabling element here is the availability of a viable workaround. For as long as the offending types remain inSystem.Reactive (even if they're marked as[Obsolete]) there will necessarily be a-windowsX.Y.Z type target for Rx, which will necessarily have a framework reference to WPF and Windows Forms. And if there were no workaround for the problems that causes, the plan outline above would not really be acceptable, because it would, in practice, be years before we could fix it.

My least favourite feature of this is thatall apps with a-windows TFM using Rx.NET end up needing to apply the workaround, and that this will continue to be the case for however many years it takes us to feel that the problematic types have been[Obsolete] for long enough that it's OK to remove them. Given that Rx.NET has aSystem. prefix (meaning people often perceive it as being somehow an 'official' component, an impression reinforced by Rx.NET 5 claiming to be part of the ".NET 5.0 wave") we can't move quickly on that, so I could see us wanting to wait 5 years before removing the types. That's a long time for a workaround to be required as part of "normal" usage. Perhaps we'd want to haveSystem.Reactive detect when you've ended up with the-windows target, and to issue a warning unless it can see that you've either set<DisableTransitiveFrameworkReferences> or you've got a reference toSystem.Reactive.Integration.Wpf orSystem.Reactive.Integration.WindowsForms.

For this reason, I think that even with this workaround we should consider aSystem.Reactive.Base component enabling components or apps to indicate completely unambiguously that they have no intention of using the WPF/WinForms bits, and forSystem.Reactive to become a bunch of type forwarders to that (but forSystem.Reactive to remain the primary point of entry for most Rx users).

The inclusion of Wpf with Winforms may be due to some containers for Wpf included in Winforms, but I don't believe that you get all the dependencies of Wpf just the ones required for the container.

DisableTransitiveFrameworkReferences was added to dotnet/sdk here:dotnet/sdk#3221

This is something that I had also thought about with the potential use of Source Generators to provide a variation of output, I haven't tested this ability but I can see the potential of it working.

How would you avoid the problems described at:

• https://github.com/dotnet/reactive/blob/feature/packaging-adr/Rx.NET/Documentation/adr/0003-windows-tfms-and-desktop-framework.md#clean-starts-arent-due-to-extension-method-ambiguity
• https://github.com/dotnet/reactive/blob/feature/packaging-adr/Rx.NET/Documentation/adr/0003-windows-tfms-and-desktop-framework.md#option-2-clean-break-introducing-new-packages-with-no-relationship-with-current-rx

But there needs to be documentation to help old versions update to new versions

The difficulty is that it can put existing projects into impossible situations. It's not merely that we need to provide documentation. That documentation would have to say "Sorry, you're out of luck."

The reasons that a "clean break" can actually make things worse are described here:

• https://github.com/dotnet/reactive/blob/feature/packaging-adr/Rx.NET/Documentation/adr/0003-windows-tfms-and-desktop-framework.md#clean-starts-arent-due-to-extension-method-ambiguity
• https://github.com/dotnet/reactive/blob/feature/packaging-adr/Rx.NET/Documentation/adr/0003-windows-tfms-and-desktop-framework.md#option-2-clean-break-introducing-new-packages-with-no-relationship-with-current-rx

Angular isn't a great model because that's a framework, and as such tends to be a top-down sort of a choice. In Rx you can get a situation where you use multiple libraries all depending on slightly different versions of Rx without you even knowing they were using it.

You don't become an Angular application as a side effect of one of the libraries you're using taking a sneaky dependency on Angular! But that's exactly how you can end up as an Rx user. And really, it's the dependency scenarios that make this tricky. If we only had to care about applications making explicit decisions to use Rx, this would be a whole lot simpler.

When a new version of Angular comes out, an application developer will decide if/when to take that change, and will typically accept that this is going to involve some planning and a coordinated effort to update the app. That's because it's an application framework. Rx really isn't. You don't write an Rx app.

Hmm. I can't repro those errors - if I useObservable.ObserveOn in a WinUI project, it only appears to find the overloads taking anIScheduler or aSynchronizationContext. I'm not able to provoke those particular errors.

That said, I think this issue of there being two versions ofWindowsBase might actually prove to be a showstopper. (The workaround really only affected the later stages of the build, preventing WPF and Windows Forms from being packaged into your app. This causes problems earlier on in the build, and I don't think there's anything we can do to resolve it.)

So I think we might end up having to turnSystem.Reactive into a type forwarding facade, and make a new NuGet package with just the non-UI-framework-specific Rx bits in after all. Sigh.

I apologise for not replying to this earlier. Somehow I never saw this thread until you referred me to it in that other discussion.

@idg10 I updated my test project and still get the errors. Do you not see them on buildingReactiveWinUIAppTest.csproj fromhttps://github.com/kmgallahan/ReactiveWinUITests?

OK, I've finally found the time to look at this. I think there are a few things going on.

This particular message is just my attempt to collect my understanding of what your example shows. It does not offer any solutions. This just feeds into the set of things we need to consider in the design of any solution (but it might well rule out the workaround proposal. Something your example reveals shows that we might have no option but to do the full package split after all.)

This code inWindows.xaml.cs seems to be what makes the issues in Rx here become a showstopper:

Observable.Interval(TimeSpan.FromSeconds(1)).ObserveOn(DispatcherQueueScheduler.Current).Subscribe(_=>{});

In particular, it's the middle line, the use of the extension method,ObserveOn. Theintent of that code is that you want to use the overload that takes anIScheduler. So the intent is that it's equivalent to this more verbose code:

IObservable<long>interval=Observable.Interval(TimeSpan.FromSeconds(1));ISchedulerscheduler=DispatcherQueueScheduler.Current;IObservable<long>intervalOnDispatcher=Observable.ObserveOn(interval,scheduler);intervalOnDispatcher.Subscribe(_=>{});

(Apologies to those who prefervar, but the precise static types are highly relevant to the problem, so it's easier to understand what's happening when you can see exactly what those types are.)

This actually compiles without error (although we still get warnings from NuGet). And the reason for that is that we've told the compiler exactly whichstatic method we want. If we replace the 3rd line with this:

IObservable<long>intervalOnDispatcher=interval.ObserveOn(scheduler);

That's when we get these errors:

1>C:\dev\temp\rxrepros\kmgallahan\ReactiveWinUITests\ReactiveWinUIAppTest\MainWindow.xaml.cs(47,50,47,68): error CS0012: The type 'Control'isdefined in an assemblythatis notreferenced.You must add a reference to assembly 'System.Windows.Forms, Version=6.0.2.0,Culture=neutral,PublicKeyToken=b77a5c561934e089'.1>C:\dev\temp\rxrepros\kmgallahan\ReactiveWinUITests\ReactiveWinUIAppTest\MainWindow.xaml.cs(47,50,47,68): error CS7069: Reference to type 'Dispatcher' claims itisdefined in 'WindowsBase', butitcould not be found1>C:\dev\temp\rxrepros\kmgallahan\ReactiveWinUITests\ReactiveWinUIAppTest\MainWindow.xaml.cs(47,50,47,68): error CS7069: Reference to type 'DispatcherObject' claims itisdefined in 'WindowsBase', butitcould not be found

The proximate cause here is that by using an extension method, we've forced the C# compiler to considereveryObserveOn extension method defined by everystatic class in a namespace for which there is ausing directive in effect. The working example calledObservable.ObserveOn directly (meaning the compiler only had to look at theObservable class). But using the extension method syntax means it now also has to look atControlObservable andDispatcherObservable, because those types are inSystem.Reactive.Linq, and this source file hasusing System.Reactive.Linq; at the top.

Since we forced it to look at all theObserveOn extension methods defined by those types, the C# compiler now has a problem: it can't actually understand those methods, because they refer to types that appear to be unavailable. The exact nature of this problem is slightly different for the first error vs the other two errors.

The problem described by the first error is simply thatControlObservable.ObserveOn refers toSystem.Windows.Forms.Control. That type that is unavailable in this project because this is not a Windows Forms project.

The problem described by the next two errors is a bit more subtle. TheDispatcherObservable class includesObserveOn extension methods referring toDispatcher andDispatcherObject. These are somewhat different than the Windows Forms issue, in that these are defined inWindowsBase.dll, an assembly that we do in fact have a reference to in this project. However, it turns out thatWindowsBase.dll is weird: the .NET SDK supplies reference assemblies for v4.0.0.0 ofWindowsBase.dll, but this has a drastically reduced surface area.

On my system with SDK 9.0.300 installed, I find that for your example project (which targets .NET 8.0) this reference assembly is atC:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.16\ref\net8.0\WindowsBase.dll, and if you open that up in ILDASM, you'll see it defines no types of its own. It contains only type forwarders, and it seems to cover four areas of functionality:

• Collection change notification (INotifyCollectionChanged<T>,ObservableCollection<T>, and related types
• System.IO.Packaging types (which were originally introduced to supportXPS)
• Some attributes in theSystem.Security.Permissions namespace (e.g.,MediaPermissionAttribute,WebBrowserPermissionAttribute; these are all part ofCAS, which still works in .NET FX, but has never been supported in .NET Core or modern .NET)
• ValueSerializerAttribute, a XAMLism

This is a fairly small subset of all the things that older versions ofWindowsBase.dll cover.WindowsBase.dll started out as a WPF thing, but because WPF was initially conceived of as a core OS component, this ended up being home to a bunch of slightly more general-purpose things, and I guess the idea with the stripped-downWindowsBase.dll v4.0.0.0 is that it holds just the general-purpose bits that are supported in modern .NET.

However, later versions ofWindowsBase are made available inMicrosoft.WindowsDesktop.App (e.g., with SDK 9.0.300 installed, I see one at"C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\8.0.16\ref\net8.0\WindowsBase.dll"), and these include all the WPFisms such asDispatcher, which is the type that Rx'sDispatcherObservable expects to exist inWindowsBase.dll.

So we've got this weird situation where v4.0.0.0 ofWindowsBase reduces the API surface area, but subsequent versions put it all back!

A problem with depending on a later, fully-featured version ofWindowsBase is presumably that it puts you back into a situation of dependence on WPF. Rx.NET tries to have it both ways: it builds against later versions ofWindowsBase (5.0 or 6.0 depending on which Rx version you use) but doesn't expose this dependency to the outside world: it will tolerateWindowsBase 4.0, but this leads to failures if you try to use anything in Rx.NET that depends on the 5.0+ feature set ofWindowsBase.

But this isn't really a tenable situation because application code can find itself causing a compile-time dependency on WPFisms in an app that doesn't target WPF. The nature of extension methods mean that source code that never meant to depend on WPF (and which would produce no runtime dependency on WPF, because it actually compiles down to one of the overloads that doesn't use WPF) can cause acompile time dependency on WPF that will cause the build to fail because the compiler is unable to understand the Rx.NET code in question.

There's one particularly important conclusion:

If the-windows TFM for Rx.NET includes Windows Forms support, any project that tries to use that TFM will encounter this error when trying to useObserveOn. Likewise, if this TFM of Rx.NET includes any WPF support, any project that tries to use this TFM will also encounter errors when trying to useObserveOn.

Not for the first time with Rx.NET's packaging problems, extension methods rule out certain strategies. (They are the reason the oft-suggested "clean break" approach doesn't work.)

At one point, Rx.NET was actually attempting to work around this problem but as far as I can tell, this didn't actually work. Up to and including Rx 5.0.0, we had a.targets file that was meant to give you thenetstandard2.0 build on .NET Core/.NET 5,unless eitherUseWPF orUseWindowsForms was set. That was introduced back with .NET Core 3.0, at a time before OS-specific TFMs existed. The logic was still in there in Rx 5.0.0 even though OS-specific TFMs did exist by that time, meaning in theory that even when your app has a-windows TFM, you would not get the-windows version of Rx unless you had set eitherUseWPF orUseWindowsForms.

In practice, that didn't actually appear to work, becauseAvaloniaUI/Avalonia#9549 shows that they pick up the-windows build in a console app that does nothing more than add a reference toAvalonia.Direct2D1. It also doesn't help with your example: if I downgrade the Rx reference to 5.0.0 (which still contains that logic that is supposed to detect when you didn't ask for WPF or Windows Forms, and to give you thenetstandard2.0 version), the compiler errors still occur, indicating that the build system is in fact supplying the compiler with thenet5.0-windows... version of Rx, despite the logic in thebuild/System.Reactive.targets file that's suppose to avoid that.

(You suggest that maybe adding similarUsesWinUI detection might help, but I'm fairly sure it wouldn't: the intent of that targets file was to use thenetstandard2.0 unless you had eitherUseWPF orUsesWindowsForms set. If that had worked as intended in Rx 5.0.0, then your example would work fine with Rx 5.0.0. But it doesn't, because that trick in the targets file appears not to have worked as intended.)

Since a) this didn't work as it was meant to and b) by May 2024 there were no versions of .NET still in support that didnot understand OS-specific TFMs, I removed thatbuild/System.Reactive.targets file. I'm fairly sure that changed nothing because, as just described, it didn't appear to do what it was supposed to: a non-WPF, non-Windows-Forms app targetingnet8.0-windows10.0.19041 using Rx 5.0 would end up with thenet5.0-windows10.0.19041 rx target and not, as that.targets file apparently intended, thenetstandard2.0 target.

Something your example reveals shows that we might have no option but to do the full package split after all.

@idg10 is this option of doing a full package split already part of the existing PR, or documented briefly elsewhere?

There has been so much written about this topic over the last couple of years that I for once have started to lose track of the current state of things. More than the ADR, I think having theshortest distillation possible of what the current proposal is shaping up to be would be invaluable.

I think most agree with everything you say, and also feel there is no option to go back to having a full split between Rx schedulers and the rest of the framework. I believe the only bit left was naming, which I believe remains important to avoid having another round of regrets later on.

@idg10 Thanks for taking the time to look into these errors.

I do not have much more to add other than my full support for a break to dump as much legacy cruft as possible.

When compared toR3 Rx.NET appears to be stuck in a quagmire. My main issue there is lack of DynamicData support (issue).

@idg10 In the spirit of summarising these very long-winded discussions, it would be useful to include a very high-level summary with the executive decisions taken: specifically the exact names of the packages should be made more clear for everyone to comment, since we will all be living with the aftermath of this for the foreseeable future.

For the record, I still don't like the names, and in general I find inertia to be a poor judge of quality. I will take some time this week to think of alternative ways forward.