Default Implementation of IObservable<T> in .NET Framework

Question

Is there any default implementation for IObservable in the .NET framework itself or I have to use 3rd party frameworks like Rx? The reason I am asking is that I am trying to create a reusable component that needs to expose a property of type IObservable and I don't want to tie this component with any such 3rd party framework.

EDIT: What I meant by 3rd part is that the implementation is not part of BCL. even though Rx is owned by MS it is not part of core .NET framework

Answer 1

There is no implementation of IObservable<T> in the .NET BCL. That said, I strongly advise against writing your own. Like, REALLY strongly. Times a million. Use the Rx Framework. If there is a policy that prevents you doing that it's so very, very wrong. Like your implementation would almost certainly be if you tried it yourself.... It's deceptively hard to get right. Not even one of the many investment banks I've worked at (who are usually the biggest pansies when it comes to 3rd party code) have been daft enough to not let Rx be used. I might be being a bit too flimsy, vague and indirect with this advice, in which please forgive me.

Answer 2

I personally think this is a great question. The OP wants to limit his dependencies, and thus create a more robust library. Kudos to that.

However as it stands, the other comments/answers speak from a great deal of experience. To implement your own IObservable<T>/IObserver<T> is not a good idea. But I also note you didn't say you wanted to.

The current answer is simply, no - there isn't an implementation of the IObservable<T> / IObserver<T> interfaces in the BCL. This was a conscious decision from MS to allow Rx to evolve at a cadence faster than the BCL. This means that in practical terms you need to take a dependency on Rx via Nuget. For your code to really have any functionality it would need at least Rx-Linq (and thus Rx-Core & Rx-Interfaces) which has Observable static class for access to Observable.Create, Interval, Empty etc.

If you component was a UI component then you may need to take a dependency on Rx-Main and Rx-PlatformServices. Luckily for you the cadence for Rx releases is quite slow now, and they are careful to follow semantic versioning, so minor version releases should not break your code and allow you to have flexible dependencies on Rx. This will give your clients the ability to target newer versions of Rx if they did come out and your lib should still work fine.