I'm working on a .net 3.5 app and I'd like to know if there is a workaround or other software that can provide similar functionality to IObservable and especially Observable.FromEvent
The app runs inside mediabrowser so I absolutely have to stay with .net 3.5 otherwise I'd happily upgrade to 4.0.
You dont need 4.0 if you want RX. You can have RX for 3.5
Related
I recently posted a question on Using Delegates to simulate connected objects where I received a great answer on using the TPL DataFlow library to very easily and cleanly develop a solution to my application.
The problem is that I am stuck on .NET 3.5 or under for C#. I thought I might have been able to upgrade to .NET 4.5 be I cannot at this stage. As far as I've been able to determine I cannot retarget the Dataflow library to .NET 3.5 so my next solution is to look for a C++ alternative under a similar vein to that of TPL Dataflow - Its not the best scenario but I can compile C++ code to a DLL and import it to our C# application.
To summarize my requirements for a C++ library for this question:
I need to be able to connect nodes together in complex networks and pass units of a resource between them. Some of them will produce finite amounts of resource over time. Others will consume it at a specific rate.
You might consider using mono's version of TPL Dataflow and compiling it yourself for .Net 3.5.
I think the biggest problem you'll encounter when trying to compile that code is that it relies heavily on TPL, which is not normally available for .Net 3.5. But it seems a backported version is available in older versions of Rx, so using that could work.
(Also, parts of the mono's version of TDF was written by me and I didn't receive pretty much any feedback about it, so it's quite certain there are bugs in there.)
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.
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.
I've seen questions and answers about why .Net framework 3 or 3.5 or 4 are good. But I've got an app that compiles well in all of these versions including 2. I was curious to know whether there would be a problem if I compile my app with .Net 2 and distribute it. (Version 2 is natively suuported by many versions of windows.)
Is there a performance or speed issue with the older versions or something that I should know of?
Many Thanks
No, there's no problem continuing to use .NET 2 if you want to.
To my mind the principle benefit of using .NET 3.5 would be that you could use LINQ (without extra libraries such as LINQBridge) which may well make your code simpler.
.NET 3 and .NET 3.5 were additions to .NET 2, so there shouldn't be any performance difference - with the caveat that .NET 3.5 came with .NET 2.0 SP1, so there were a few modifications... but if you run a .NET 2.0 application on a machine that has .NET 3.5 installed, it'll be running the SP1 code anyway, so it makes no difference whether you've actually targeted .NET 2.0 or 3.5.
well,not really.
If your app runs on 2.0 then it can also run on 3,3.5 and 4.0 since they are backward compatible.
If you get along with 2.0 then compile for 2.0 there is no reason to artificially raise the requirements.
However if you are not using any 3.0+ features I would recommend you to learn about all the new features. It will speed up your development and improve your code.
How far back does the argument hold? If the original question had asked why go with 3.5 or 4.0 if 1.0 works would the answers be different?
At some point there's risk in clinging too long to an out of date platform. You might still be okay with 2.0, but 2 versions behind might be as far as I'd push it.
I think it really depends on your use-case.
Is this app:
A client you deploy to all sorts of windows clients (e.g. consumer-type win app)
A client you deploy to your enterprise (and they'll manage .net versions)
A server-side app on your data center
A server-side app you sell and others install
etc.
If it's #1, then you want to target .NET 2 if that suites your needs. You probably want the least amount of frictions for your users in terms of not updating .NET. Windows 7 comes with .NET 3.5, Vista with .NET 3 (similarly for the server OSes).
If you know you're targeting Win7 users and above then .NET 3.5 is fine. As the other posters mentioned, the main benefits of .NET 3.5 vs 2.0 is really
LINQ
WPF
WCF
If you are a #2 scenario above, then by all means, use .NET 4. There are many improvements including LINQ, but also in the runtime and if you control the systems then it's definitely worthwhile to be 6 years in the future from a software perspective. Even more so for #3.
For #4, you'll have to decide whether that's an issue for your clients. Most the time it's not, but it can be.
Of course, you can use VS 2010's Multi-Targeting feature to use modern tools regardless.
Not too long ago I wrote the client part of http://chatpast.com which has to be installed. As painful as it was, I wrote that in Windows Forms and .NET 2.0 because that was the least likely to cause problems for users and require a .NET install / upgrade. But the server-side code is all .NET 4.0.
So I guess you can even say that it's not purely and either/or choice. Think about what makes sense for each part of your deployment.
I'll be developing a C# networking application which will make use of UDP and will require lowest lag time and general good performance.
Is .NET 3.5 better suited for such applications? Is there any performance benifits/improvements in .NET 3.5?
Specificly I'll be using SocketAsyncEventArgs class. And I think it is available from only .NET 2.0SP1+?
Is .NET 3.5 better suited for such applications?
They are the same. Except that 3.5 is just a better language.
Is there any performance benifits/improvements in .NET 3.5? Specificly I'll be using SocketAsyncEventArgs class. And I think it is available from only .NET 2.0SP1+?
The .NET 3.5 technically is just add-on on top of .NET 2.0.
So in 3.5 you will have all the same Pros/Cons of .NET 2.0 plus all the additional language improvements.
For me there is no doubt - .NET 3.5 would be my choice because of all the language sugar that heavily increases productivity.
I want to use something similar to the BackgroundWorker, which is known from the full .NET Framework, on mobile devices. Sadly it is not available in the compact framework.
What can I use instead?
There is an MSDN site discussing the Background Processing Techniques on the CF.
The most common option is to use ThreadPool.QueueUserWorkItem instead of a BackgroundWorker, although there are other options.
There is implementation of BackgroundWorker for CF:
http://www.danielmoth.com/Blog/2004/12/backgroundworker-sample.html
Here is an implementation that was created using Reflector. You could use Reflector to check out various implementations within the .NET framework
There is a framework, called Smart Device Framework by OpenNETCF, which tries to fill the gap between the compact framework and the full .NET framework. This framework contains and provides a BackgroundWorker implementation.
This framework is available as a community version, which can be used for free.
From the old version 1.x is also the source code directly available from here (scroll down to the last link). This source code is similar to the link, which #Filip Navara provided.