反应式扩展 .NET 3.5 中的 ConcurrentDictionary 在哪里
我的问题很简单。经过大量谷歌搜索后，我了解到我可以在使用Reactive Extensions和System.Threading.dll<的.NET 3.5项目中使用ConcurrentDictionary /strong> 其安装目录中的版本。首先，Reactive Extensions .NET 3.5子目录中没有System.Threading.dll，只有System.Reactive.Windows.Threading。 添加对 System.Reactive 或 System.Reactive.Windows.Threading 或提到的 .NET 3.5 中的任何其他引用不会给我 ConcurrentDictionary 类，也不会给我 System.Collections.Concurrent 命名空间。已经下载了旧版本的 Reactive Extensions SDK，我找到了我一直在寻找的东西，但我的问题是：有人知道在 Reactive Extensions 的实际版本中 ConcurrentDictionary 向后移植发生了什么吗？有人知道在哪里吗？它是或者为什么它丢失了。我找不到合理的答案或根本找不到任何答案。
My questions is simple. After heavy googling I have learned that I can use ConcurrentDictionary in .NET 3.5 projects using Reactive Extensions and System.Threading.dll version from its install directory. First of all there is no System.Threading.dll, there is only System.Reactive.Windows.Threading in Reactive Extensions .NET 3.5 subdirectory. Adding reference to System.Reactive or System.Reactive.Windows.Threading or to any other from the mentioned .NET 3.5 doesn't give me ConcurrentDictionary class nor it gives me System.Collections.Concurrent namespace. I have downloaded older version of Reactive Extensions SDK and I have found what I have been looking for but my question is: does anybody know what happened to the ConcurrentDictionary backport in actual release of Reactive Extensions, does anybody know where it is or why it is missing. I was not able to find a reasonable answer or any answer at all.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们不再为 .NET 3.5 提供带有 Rx 的 TPL 向后移植。如果您想在并发领域使用 TPL 和相关创新，请开始使用 .NET 4（或更高版本）。 Rx 本身不需要 TPL 功能，因此我们没有强烈的需要携带 TPL。
与保持这种向后移植相关的可支持性、维护和质量方面存在太多复杂性。例如，旧 CLR 版本上的 TPL 性能特征从未经过过超出几年前 TPL 初始 CTP 的测试。
We no longer ship the backport of the TPL with Rx for .NET 3.5. If you want to use the TPL and associated innovations in the field of concurrency, start using .NET 4 (or beyond). Rx itself doesn't need TPL functionality, hence there was no strong need for us to carry around the TPL.
There are too many complications with regards to supportability, maintenance, and quality associated with keeping such a backport alive. For instance, performance characteristics of the TPL on older CLR versions has never been tested much beyond the initial CTP of the TPL several years ago.