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.
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.)
How can I integrate the SignalR references and Dlls into a 3.5 project ?
Three options:
you don't use it
you upgrade your project to a more recent framework (presumably 4.5)
you do the work to make SignalR work on .NET 3.5, possibly submitting a pull request
The web world moves rapidly; .NET 3.5 was released in November 2007 - over 5 years ago. Forcing all library authors to restrict themselves to this, when the vast majority of projects are going to be for 4.0 / 4.5 is prohibitive. Some projects may choose to do this, some may some may offer a restricted subset of features on older platforms, and some may elect that it simply isn't worth the overhead to support (a lot of effort, to support a marginal and declining user base).
Frankly, I think you should treat this as a reason to consider upgrading framework.
In particular, I can imagine SignalR wanting to make use of the WebSocket and improved async IO features, the MVC hooks, plus the http-context stubbing features (for unit tests). But possibly a lot more (I haven't checked).
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
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.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why should I upgrade to c# 4.0?
Our projects are currently all C# 3. If we dont have a specific requirement for features that C# 4 provides, would there be any other reasons for us to upgrade? Thanks.
Edit
There seems to be more of an advantage with using the new CLR and not just the new language features.
I personally don't feel that there are great language enhancements between C#3 and C#4 if you're targeting the same framework (2.0-3.5).
However, if you move to .NET 4 CLR as well, I think there are all sorts of benefits in the runtime you can take advantage of. My favorite feature is the parallel task library.
It depends on what you want to do. I don't there are killer language features that 2.0 (Generics) and 3.0 (LINQ and Lambdas) had. C# 4 is more scenario based (see list below for some). If you want to:
take advantage of the new features in WCF (default endpoints, improved WCF REST support, etc.);
work with Entity Framework 4 and it's new features along with WCF Data Services to expose your EF model as a data service;
take advantage of some of the multi-threaded enhancements (e.g. Tasks instead of using Threads);
CodedUI tests (more of an IDE thing, not a language thing);
etc.
...then maybe I would. (Most of my projects utilize WCF in some way, so I'm in the process of upgrading.)
I wouldn't upgrade just to upgrade. Upgrade if you have a business/technical reason to do so. You have to weigh the costs (less time coding while you upgrade your environment) with the benefits (latest language, and as one commenter said, happier developers).
Plus, the IDE is nice (although I've found it a little unstable at times). And as w69rdy's comment said, it's backwards compatible. You may want to give the IDE a try and still stay on .NET 3.5 just to try some of its features (like the extension manager and schema comparer).
If your software is fairly static and business critical then an upgrade may present a risk to the production uptime of the business. However, if you plan to continue development of the business' software well into the future then at least planning to upgrade is a step in the right direction. There's no reason to limit one's development to older versions if the company wants its code to keep moving forward. Future problems may have easier and more expressive solutions using newer language capabilities.
There's also certainly something to be said about keeping one's development staff current on technologies. If the business wants its technologies to remain static, it's going to have an increasingly difficult time finding talent over the years.
If upgrading to C# 4 is not a vey large pain for your system, then it's worth it just to have you projects on the new runtime, if .NET 4 were running on .NET 2 like .NET 3.5 is I would say don't bother, but the benefits of being on the newer runtime are futuresafety in this case since there will be future .NET releases based on the .NET 4 runtime, and the upgrade may be more difficult come that time.
I am making the assumption that you're asking if it's worth it when you don't need it because it wouldn't be extremely difficult for you to upgrade, if it would present particular risk and difficulty in your project then it would not be advisable without a sufficient business need for the functionality in .NET 4
If you are using ASP.NET WebForms it might be worth. Take a look at this blog entry.
Web.config files are much cleaner now and css support was enhanced a lot. WebForms Routing is also a core feature under 4.0. Best of all, you finally get full control over your control id's!
In my opinion, WebForms still isn't as nice as ASP.NET MVC, but it got much required love in 4.0.