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.
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).
Yes I still use the older version of the .NET Framework & love it. Would like to use a database wrapper now massive by rob is awesome if I had 3.5 but Nooooo.
You got any suggestions for a database wrapper ?
Please don't suggest a ORM(ex NHibernate, Active Record) all we do is write stored procedures and supply them parameters in our data access layer. Nothing more nothing less, we are thinking of abstracting away parameters as object now thinking wrapper might be out there or rolling out our own.
Dapper dot net - written by Sam Saffron of Stackoverflow fame - is a good alternative to Massive, and it's very similar, but also supports .NET 3.5.
https://github.com/StackExchange/dapper-dot-net
But you definitely need to upgrade to at least .NET 3.5 - 2.0 is really really REALLY old by now..... since it still uses the same CLR version (2.0), it shouldn't be any problem anyway - just upgrade - it's not more effort than installing a security update...
The 3.5 support is a bit less "elegant" in some places (like when you need to provide lots of parameters to a method call, since 3.5 doesn't have optional and default parameters yet), but it works like a charm!
It handles stored procedures without any problem - even those that return multiple result sets....
If you really cannot upgrade to .NET 3.5 (why is that again??), then the best you can do is the Microsoft Data Access Application Block - but that's light years behind the nicety of Massive or Dapper.NET .....
How about Microsoft's Enterprise Library? Older versions that will work with 2.0 are still available. I've used this in the past quite effectively (although we have since moved to the Entity Framework in 3.5).
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.
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.
I'm wondering if is it there any easy, and common between .NET and Mono, way to retrieve machine statistics (eg. free space left, total memory, etc.).
Under the .NET 2.0 profile I was able to identify DriveInfo class, but in the previous versions (1.0, 1.1) and Compact framework, which I would like to support, there's nothing like this.
I already excluded the WMI API, since it's not supported by Mono and Compact Framework.
Anyone has ideas about it?
Mono supports the DriveInfo class. You should be able to get this information the same way in Mono as you do in Microsoft's .NET implementation.
There's no way to do most of those things with .NET CF without resorting to P/Invoking Windows Mobile API. So you can strike out cross-platform compatibility with it right away.
As per making this work on .NET 1.1 (I'll pretend you did not mention 1.0...) - why? Do you have any Windows NT 4.0 clients that require this?