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.
Related
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 looking to upgrade my ASP.NET web app to the .NET 4 framework. Would I see performance improvements right away?
According to this blog post, there are supposed to be internal runtime improvements that should help out of the box.
According to Microsoft, there have
also been a number of invisible
performance improvements in the
internals of the ASP.NET runtime that
should make ASP.NET 4.0 applications
run more efficiently and use less
resources. These features come without
any change requirements in
applications and are virtually
transparent, except that you get the
benefits by updating to ASP.NET 4.0.
There is a PDC presentation (which I cannot currently find) that claimed the same thing. I would assume that YMMV depending on your implementation, in any case.
Obviously ASP.Net 4.0 will benefit from any areas of the .Net 4.0 runtime on which it depends that are improved. It's usually safe to assume that a new release will make things no worse...
A lot of the performance improvement is probably in development. A lot of things have been improved like handling of ID's so Javascript can interact better with controls. And some C#4.0 features like the dynamic object and it late binding. Here is a list of all the benefits ASP.NET 4.0 Have:
http://www.asp.net/learn/whitepapers/aspnet4
This isn't like new versions where newer versions will still have backwards compatibility.
What I mean is something like, when the designers of C#, .NET, CLR realize that they made a mistake or they overlooked something that could be hugely beneficial but now they couldn't pursue it because of backwards compatibility, they could branch the appropriate product say like by designating it in a different manner (horizontal versioning).
Wouldn't this be more future-proof?
You can say this would be a nightmare, but there would be restrictions like you can't mix and match different branches unlike the different languages that are compatible with each other, etc (in the same branch).
This way you would say use C# 4.0, then there is something very beneficial that you could use from C# 4.0 B1 (branch 1) and just use that, even though it might require some porting effort.
Is this not a healthy development strategy, where new projects could always start using the latest and the greatest, meaning the latest version and the latest branch of a particular language (C# 6.0 B4 for example)?
I don't see any extra hassle in keeping track of things for newer languages where you already have to know things for each version anyways. So this just adds another dimension (horizontal versions) to vertical versioning.
What would be the potential pros/cons for this development strategy?
There is a huge benefit to having a large set of libraries available for a platform. Currently, if I write a .NET 4.0 application I can reference libraries which were created way back on .NET 1.1. This means that there's a lot of existing code that I can take advantage of, and this is one of the major selling points of .NET.
If I understand your proposal correctly, then if library A is written against C# 4.0B1 and library B is written against C# 4.0B2, then there is no way that my application can be written to reference both library A and library B. This would fragment the platform and make it a much harder to justify the investment in writing C# applications or libraries.
Of course, there are also costs associated with backwards compatibility (look no further than Java's implementation of generics...), but in my opinion the benefits clearly outweigh them. Having a vibrant community using a language or platform makes it easier to hire developers, to find libraries with useful functionality, to get training and support, etc. These network effects are all put at risk by creating incompatible islands within the platform.
Actually, this is a bit like the way Open Source detractors used to argue Open Source projects would end up going. After all, you, I or anyone else could take any Open Source project and fork it into a different branch tomorrow.
Thankfully, the only case where this would gain any traction in the community though, is where we either took it into a specialist rôle (so that it didn't really compete with the original project, just builds on a common ancestor), or where there was massive dissatisfaction with the way the original project was run (where it's sort of a nuclear strike option in Open Source politics).
The reason it was used as a bogeyman argument against Open Source is that it would just be impossible to keep track of which version of which version of which version of which version of a given library, framework, language, component, etc. could work with which version of which version of which version of which version of another.
Luckily, whether open or closed, such branches would die a natural death in the face of the "market" (whether that market was economic or otherwise).
Many (larger) shops have enough trouble keeping up with the major revisions of .Net that are already coming out. This strategy might work for a platform that is not the predominant development platform worldwide, but for Microsoft (and many developers) it would be hell.
Backward compatibility is taken very seriously at Microsoft, especially where developers (the lifeblood of the company since Windows took off in the mid-90s) are concerned. Breaking changes have unknowable impact due to the scale of Windows, and latterly .Net, adoption. Would you want to be the guy who had to explain to Steve Ballmer why your cool fix in the new minor version of .Net broke the apps on which GE (say) run their business? There is immense effort put into making sure that legacy apps and devices will continue to run. Increasing the matrix of versions to be tested would inevitably lead to corners being cut, and we all know what happens next, right?
You can counterargue that nobody has to adopt the latest. But who here does not install Windows SPs as soon as they come out, to avoid the drip-drip of hotfixes for security issues? There is a natural inclination to want the latest, though that has to be balanced vs stability concerns.
.Net has gone a good way to removing DLL hell from the Windows developer lexicon, and to some degree decoupled developer platform progression from OS releases. I don't think the majority of Windows developers are in a hurry to see that change. Love them or hate them, Microsoft have gotten very good at managing large, infrequent releases of what is still the world's de facto desktop standard. It will be interesting to see how Google manage the same problem, as Android takes that spot in the mobile market over the next year or two.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm probably going to take some heat for this question. But I'd like to know how to address this problem. So here goes.
I program (to different levels of competence - admittedly) in various languages. I have dabbled with C#, and it seems quite a nice language (reminds me A LOT of Java and C++). The problem is that I have what can only be described as a pathological distrust of all things from the Redmond company - as a result of experiences too many to enumerate here.
I am a great believer in open source software (GPLd or otherwise) - and am an avid consumer and contributer to many Open Source projects.
My questions are the following:
.Net can ostensibly be run on Linux using mono - but is anyone actually using such a setup in production?
It seems to me that almost every (half year?) or so, a new version of the language is pushed out - (I don't know whether the new versions are backward compatable). In any event, if you take other languages e.g. C/C++, Python etc, the 'versioning' is far and few between - therefore it provides a more 'stable' environment for the developer. It seems (in my mind at least) that learning/using C# is going to be a never ending learning curve every six months - I am not sure if I have the wherewithal to commit so much to any one particular language.
To summarize, I am trying to balance the pros and cons of learning/using .Net (and C# in particular, which looks like a beautiful language), but if I do, I want to deploy on Apache/Linux (with either mySQL or PostgreSQL backend) - as opposed to IIS/Windows/SQLServer.
Is this a pipe dream (running .Net/C# on Linux), or is someone out there actually using it in production?
While C# does change periodically, it's more along the lines of 18-24 months than 6 months. Moreover, the C# team is very conscientious around making the changes as backward compatible as possible. (There will always be potential breakage when new conversions are introduced etc, but this is mostly a problem with corner cases such as overloading in the inheritance hierarchy.) You don't have to learn everything to do with the latest version... and in the case of C# 4, if you don't do COM and you don't want to use dynamic typing, there's not very much to learn anyway. The enhancements for C# 2 and 3 were much larger, of course - but then they brought much larger benefits too.
As for whether Mono is used in production - the Mono project itself has a list of companies using Mono.
There's a good list to be found at http://mono-project.com/Software and http://mono-project.com/Companies_Using_Mono one good example "Electronic Arts used it to power Sims3."
New C# versions are pushed out at a quite good pace but the underlying VM specification haven't changed since standardization, backwards compatibiltiy between language versions isn't a problem but you need to target the correct Runtime Version but that's the exact same problem you'd have with Java.
The weakest part of the .Net ecosystem is probably that open source haven't progressed as far as in the Java sphere but things seems to slowly be improving, uptake and contributions will only help that. There's much good stuff comming out of the Alt and Progressive .Net camps in that regard.
The Wikipedia page for C# shows that your feelings about frequency of new language versions are far from the truth. Certainly the MS way has always been to keep up the flow rate of new technologies - see for example Joel's old essay Fire and Motion - but there's rarely a compelling business reason to keep up with the latest shiny. But the existence of that strategy on MS's part is no reason to keep you from using what is as you say a very nice language, which is independently standard-ised.
If you really want to do web development and host it on linux, .Net / Mono ain't your best choice.
Although ASP.Net seems to run (WebForms that is), ASP.Net MVC (2) does not, at least not flawlessly, so it depends on how well you know Linux to work around bugs that will arise.
Personally, I found it easier to just learn Ruby and use Ruby on Rails than to work around awkward bugs regarding ASP.Net MVC with Mono.
For desktop clients, Mono is a viable alternative.
As for C#: In my opinion it is a nice language too and with the .Net framework it is really productive for windows clients. The changes aren't that bad and you don't have to use every shiny new feature, but you can.
Our one and only enterprise application suite has been developed over last 3 years using C# 2.0 on .Net 3.0. We use winforms and WCF heavily. The development tools is VS 2005 Pro / TFS 2005 / Resharper 3.1
As technical lead I obviously understand the benefits in a move to C#3.0 and .Net 3.5. But I want to convince management for a move to C#3.0, .Net 3.5, VS 2008 and TFS 2008. They will obviously be interested in things like productivity, cost, quality etc. Please suggest me some ideas on how best to make my case.
Given that this may not happen till mid next year am I better off to hold till VS 2010 and .Net 4.0 is out.
"If we don't upgrade to newer technologies, it will be more difficult to hire good developers, and those who we already have will be fleeing soon... probably including myself..."
Is there much in .NET 4.0 which will benefit you? C# 4 itself doesn't have many new features... whereas I'd expect you could make good use of the C# 3 features. .NET 4.0 does have some very cool things (in particular Code Contracts and Parallel Extensions) but you should really look at what you would use.
If management is nervous about changing framework version, you could upgrade to VS2008 and use C# 3 but still target .NET 2.0. (Most of the C# 3 features still work when targeting .NET 2.0.) Using LINQBridge you could even still use LINQ to Objects, which is hugely beneficial IMO.
Of course if you can upgrade to .NET 3.5, you'll clearly get more opportunities for LINQ goodness, etc.
Whip out the Microsoft expiration schedule on technologies, figure out how long your current solution set will be supported.
Look to things like Linq-to-Entities. If you don't currently have an ORM, this is a huge time saver.
It's always easier to upgrade version by version than it is to jump several versions. I learned this over time. Step by step upgrades were almost always painless. Upgrades that jumped multiple versions required a signficantly larger amount of extra code and testing.
Identify the top 5 features in your "nice to have list". How many of them are only provided by, or provided in a better way, by the new version?
Don't push for bleeding edge. There's a cost to being on the very edge of emerging technology. That cost is often very hard to justify from a business standpoint.
You have change code anyways. Figure up the cost of the next X feature changes. Try to roll it into a release. "We can do it as part of XYZ release with only NN extra hours, saving MM hours over the next six months".
Look around the web for stats on code rollover. Most custom systems are "rewritten" gradually over time as the business process changes. However management tends to view software as a "write once, use forever" endeavor with only some maintenance costs. Make sure they understand that this is them taking control of the upgrade process, and them guiding the future of their tool in a planned fashion, as opposed to just whatever comes out after dozens of minor changes.
Edit: This all assumes that there actually is a cost justification, which you will hopefully answer for yourself while going down this list.
I don't think any productivity gained by going from C# 2.0 to C# 3.0 can be easily justified for a particular project. Rather than try to justify moving to the new version of the language, think about why you wouldn't?
Does the group want to stay with VS2005 forever, or are they planning on moving to VS2008 some day. If they want to stay at VS2005, consider the fact that that compiler is now on extended support, pretty soon it won't be supported at all, and you won't be able to get even security updates, similar to VC6. Furthermore, the new version of Microsoft's SDL (5.0) requires the use VS2008 or later.
If the group is willing to move to VS2008 eventually, then determine if you can work in a mixed mode environment. This can work effectively if you have a large code base, so new components are built with the newer tools.
Once the team / project has moved to VS2008, then using C# 3.0 features as opposed to sticking to the C# 2.0 subset shouldn't really be an issue.
For VSTS, the best thing to do is to try to use it on a new project.
You will have to upgrade from C# 2.0 to get LINQ. This technology is very powerful, not only for querying databases, but for development in general.
Upgrading should (at least in theory) be easy. You recompile and pay attention to warnings about obsoleted calls.
The biggest problems I've ever run into when trying to upgrade an enterprise application and convincing management was because of the deployment cost. When you upgrade to .NET 3.5, all your clients will have to get the 3.5 framework. Depending on your end user audience, this could be a big deal. That was the holding factor for management whenever we tried to pitch it. The language features, framework features, and other benefits/costs really didn't matter much to them. The deployment cost kept ringing in their ears. If you can make the deployment cost minimal (i.e. you might roll the 3.5 framework into the next install or something), then you'll probably be able to show that the productivity benefits far outweight the costs. Otherwise you might find yourself in the situation I found myself in.