.NET Framework Version Comparision(jinaldesai.net)
jinaldesai.net
.NET Framework Version Comparision
http://jinaldesai.net/net-framework-version-comparision-table/
It is frequent usage to see all the .NET Version with it’s features on one page. While surfing on net it is difficult to find or even not a single site provides all version on one plate with features. Following is a try to put all the .NET Framework versions together with other release and features details.
8 comments
C# as a language had numerous and interesting features implemented in the last years. I always wished that Java was that fast in making improvements, instead of spending years for every decision.
Moreover due to the fact that .NET is coupled with Windows, it seems to be less of a problem to be stuck with a very outdated version of the framework.
In Java I often had to write for version 4, whereas 6 was already released.
Agreed, apart from nullable types which I think is a misfeature (having dealt with the inevitable null reference/null value tristate hell left by some developers).
.NET won't allow you to create a Nullable<T> where T is itself a nullable type. (And Nullable<T> is not itself nullable.) I'm not sure about all languages, but in C# code like that won't even compile.
I agree, allowing a nullable wrapper around a (already inherently nullable) reference type would be a horrible misfeature. What language was that?
I agree, allowing a nullable wrapper around a (already inherently nullable) reference type would be a horrible misfeature. What language was that?
I just wish that rather than adding nullable primitives they added non-nullable objects. The type system used by googles javascript compiler has support for those and working with it is fantastic.
That would be fantastic - great idea!
No More:
No More:
Check.IsNotNull(objRef, "stop being a muppet");I thought .NET types were optionally nullable? I don't think they are by default.
Basic types are optionally nullable. int? is nullable, int is not.
It is a fantastic tool in many cases where a null is much clearer than something like -1 to denote a missing value.
However, I can see the issue with some developers using nullable types for everything. But any sufficiently powerful/flexible tool is always going to be misused by some.
It is a fantastic tool in many cases where a null is much clearer than something like -1 to denote a missing value.
However, I can see the issue with some developers using nullable types for everything. But any sufficiently powerful/flexible tool is always going to be misused by some.
I had the misfortune in the past to maintain C# code that kept everything as strings; whether it was an integer, a floating-point number, a guid, a date or a boolean. Lousy developers can abuse anything, in itself in my opinion this is not a reason to not have it included.
(I have a the same opinion about goto and operator overloading; clearly the folks at Microsoft agree with me here.)
(I have a the same opinion about goto and operator overloading; clearly the folks at Microsoft agree with me here.)
They are optionally nullable. Unfortunately, people seem to think that making use of them everywhere is cool :(
Scala might be an option for you. It is not as "stable" as Java, but more like C# and it actually has a real "deprecation cycle", e. g. stuff gets removed after two versions, both in the language and the library. Pace of development is actually really impressive. If you are interested, I wrote down some nodes about the keynote at ScalaDays here: http://hackerne.ws/item?id=3912885
I think that the "deprecation cycle" is ultimately hurtful for Scala. Breaking changes in a programming language are immensely difficult and expensive for enterprises to deal with, and breaking changes in core libraries are no picnic either. I'd be extremely hesitant to advise my employer to adopt a language whose maintainers have a cavalier attitude about such things, because it does really bad things to our ability to predict costs.
It is certainly not worse than anywhere else (see for example what happened with Windows RT/Metro ... that was certainly magnitudes worse and Microsoft still decided to do it (or the breaking changes in C# 5)).
The only exception is Java, where everything is basically frozen after release and cannot ever be changed anymore.
Most of the time, targeting a newer version in Scala is just a recompilation away, like on .NET. So if you are good with .NET, you should be good with Scala, too.
The only exception is Java, where everything is basically frozen after release and cannot ever be changed anymore.
Most of the time, targeting a newer version in Scala is just a recompilation away, like on .NET. So if you are good with .NET, you should be good with Scala, too.
I'm so desperate for C# .NET stuff to show up on HN that I'm even willing to vote up this uninteresting, unreadably-formatted blog post.
While I generally use Scala for my personal projects I'm a .NET/C# dev by trade. There are definitely features about the .NET ecosystem that I wish I had on other platforms and that they worked as well as they do on .NET. I'm thinking about features like LINQ (sorry, Squeryl is nowhere near that yet) and the top-to-bottom integration of VS.
I'd like to see more attention paid to it as well.
I'd like to see more attention paid to it as well.
C# needs to be decoupled from MS. It is too cool a language to be tied up with windows.
As a certain lawsuit is illustrating, C#/.NET is much less coupled to MS than Java is to Oracle. Oracle is suing Google for creating an implementation of Java without their blessing, a clear indication that they believe they own and control the platform. By contrast, Microsoft has issued a legally-binding pledge not to sue people for creating their own implementations, and published the platform's spec as an open standard.
Mono admittedly lags a bit behind Microsoft's implementation of the platform, but that's mostly a question of resources. If Mono had been embraced by the open source community the way Java has been (as it should - see previous paragraph), then that wouldn't quite be the case.
Though not by much, and not in all respects. That crew is doing some really great stuff.
Mono admittedly lags a bit behind Microsoft's implementation of the platform, but that's mostly a question of resources. If Mono had been embraced by the open source community the way Java has been (as it should - see previous paragraph), then that wouldn't quite be the case.
Though not by much, and not in all respects. That crew is doing some really great stuff.
I've been saying this for a while now that I'm starting to sound like a doomsday-sign-carrying lunatic. C# is really enjoyable to code in, but it's a shame that it's stuck on Windows.
Be aware that there also exists a "NET Compact Framework" used on the XBox, Silverlight and Mobile devices. This caught me off guard when I tried to get JavaScript running on the XBox[1], since it has a different, stripped down feature set than the real NET Framework.
[1] http://www.phoboslab.org/log/2012/04/javascript-on-the-xbox-...
[1] http://www.phoboslab.org/log/2012/04/javascript-on-the-xbox-...
The compact framework can also be used on Windows desktops and can make sense if you want to bundle dotnet with your app (because you want to improve the installation experience) while minimizing download size and you don't need features from the real dotnet framework.
For what it's worth 4.0 also added co-variant and contra-variant generics which are surprisingly useful.
Co- and contra-variant generics have been available since .NET 2.0 -- they just weren't exposed by any "standard" .NET language until C# 4 (which coincided with .NET 4.0).
Missing .NET 4.5, which introduces C# 5 with async support. C# is a great language. Shame it's stuck on Windows and the "enterprisey" .NET framework.
I am not sure what is enterprisey about .Net. I am working on Live Post http://livepost.in using ASP.Net MVC/jQuery/jQuery Mobile/MySQL/MongoDB/Dapper(ORM). Just replace ASP.Net MVC/Dapper with django and it will become a common stack used by alot of startups these days. Also from cost point of view the difference is very minimal - I am running it on a 1GB VPS which at my host costs just 2.95$ extra per month compared to a linux VPS with similar specs. I use Visual Web Developer 2010 express edition IDE for development which is pretty good in terms of features and is free. So its just a matter of perception nothing else.
What is "enterprisey" about .NET?
Mono is a real alternative, many businesses run it production, including the likes of Fog Creek.
Mono is a real alternative, many businesses run it production, including the likes of Fog Creek.
Just so we're all on the same page here, Fog Creek is not currently using Mono in any part of Kiln or FogBugz On Demand. We use Mono to allow FogBugz to run on Unix systems for on-site installation, and we're looking at using Mono in Kiln for similar reasons. At the moment, though, Kiln and FogBugz On Demand are 100% WISC deployments.
Sorry should have clarified that it's not run in-house but rather supported for full-on production deployments, from what I have heard.
[deleted]
.NET is very "enterprisey". It seems to be designed to make creating line-of-business applications easier.
What exactly makes it enterprisey? I am always really unclear on what makes something "enterprisey" other than perceptions.
IMO, complete integration (one solution, one vendor) across the board (from OS, to IDE, to Database, to Frameworks, etc) is what makes something "enterprisey". That, and a large and mature ecosystem built around it.
But that's not true. Plenty of .NET users do use other OSs (through Mono) and databases (I use MySQL). Sure, the best IDE is VS and there's tons more docs and support on using it all on Windows, but the same can be said of Rails with Linux and Textmate for example.
Enterprisey is a matter of perception and shouldn't be a slur.
Enterprisey is a matter of perception and shouldn't be a slur.
If you step outside of the startup bubble, you'll find that the bulk of .NET stuff is boring line-of-business apps developed by large corporations using the MS stack from top to bottom because MS is "safer" than open source.
I actually work at a .NET startup doing non-traditional things with .NET and we have the hardest time hiring new developers because of the "enterprisey" nature of .NET and the type of developer that generates.
I actually work at a .NET startup doing non-traditional things with .NET and we have the hardest time hiring new developers because of the "enterprisey" nature of .NET and the type of developer that generates.
[deleted]
The thing I like most about C# is the new 4.5 async method decorators CTP which are frankly async methods done right.
For those not in the know, you just need to add an async to the front of the method and then put in await on whatever operation is going to take a while.
You can literally take synchronous network code modify a few methods and get 100x the throughput.
For those not in the know, you just need to add an async to the front of the method and then put in await on whatever operation is going to take a while.
You can literally take synchronous network code modify a few methods and get 100x the throughput.
> You can literally take synchronous network code modify a few methods
A few methods? Visible async taints, always (think haskell monads, because that's pretty much what it is), you have to convert the complete dynamic scope leading to those newly async method or it'll never work correctly.
It's more than "a few methods" unless your system is absolutely trivial.
So no, you literally can't do that, let alone literally.
Not to mention, `async` marks the method as asynchronous, it does not make the method asynchronous:
> put in await on whatever operation is going to take a while.
That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue. At the very least, this means wrapping "whatever operation" in a `TaskFactory.StartNew`. Not just adding an `await` to synchronous code.
Ultimately, `async` and `await` still are nothing but sugar over the Tasks API.
A few methods? Visible async taints, always (think haskell monads, because that's pretty much what it is), you have to convert the complete dynamic scope leading to those newly async method or it'll never work correctly.
It's more than "a few methods" unless your system is absolutely trivial.
So no, you literally can't do that, let alone literally.
Not to mention, `async` marks the method as asynchronous, it does not make the method asynchronous:
> put in await on whatever operation is going to take a while.
That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue. At the very least, this means wrapping "whatever operation" in a `TaskFactory.StartNew`. Not just adding an `await` to synchronous code.
Ultimately, `async` and `await` still are nothing but sugar over the Tasks API.
I appreciate your perspective on this. I've been using the new Tasks from the Parallel Library and really enjoy them. But, once I started reading about the async markup I was a little unsure as to what I gained from it since as you mentioned it's really just a new way to write the task.
Personally, I haven't had the time to really sit down and play around with both to see how I feel about code legibility and maintainability between the two techniques.
Are you aware of any extra functionality gained by marking methods async? It seems the new markup is more useful for frameworks. Think async action methods on controllers for mvc rather than your own little methods.
Personally, I haven't had the time to really sit down and play around with both to see how I feel about code legibility and maintainability between the two techniques.
Are you aware of any extra functionality gained by marking methods async? It seems the new markup is more useful for frameworks. Think async action methods on controllers for mvc rather than your own little methods.
> Are you aware of any extra functionality gained by marking methods async?
As far as I know there isn't any, the gain is in code readability/simplicity from the POV of an imperative developer: async/await are hints which the compiler transforms into CPS by thunkifying code following an `await`. According to Eric Lippert's series on async/await[0], the compiler also performs complex code generation to try and make try/except blocks behave "sensibly" in this imperative-looking code. While necessary for the coding style, I still am not sure whether that's an advantage or a drawback of async/await.
> It seems the new markup is more useful for frameworks. Think async action methods on controllers for mvc rather than your own little methods.
Technically, from outside the method `async T foo()` is no different from `Task<T> foo()` I believe, it's only the internal detail which change (mostly composing async callees and returning the result of an async chain). On the other hand (again this is something drawn from Eric's post) alongside async/await the framework team will add new APIs the Tasks API set, one of them being "multiplexing" of tasks (waiting for all tasks of a set of tasks, or any task of the set, although I'm sure the community has already implemented that separately)
[0] http://blogs.msdn.com/b/ericlippert/archive/tags/async/
As far as I know there isn't any, the gain is in code readability/simplicity from the POV of an imperative developer: async/await are hints which the compiler transforms into CPS by thunkifying code following an `await`. According to Eric Lippert's series on async/await[0], the compiler also performs complex code generation to try and make try/except blocks behave "sensibly" in this imperative-looking code. While necessary for the coding style, I still am not sure whether that's an advantage or a drawback of async/await.
> It seems the new markup is more useful for frameworks. Think async action methods on controllers for mvc rather than your own little methods.
Technically, from outside the method `async T foo()` is no different from `Task<T> foo()` I believe, it's only the internal detail which change (mostly composing async callees and returning the result of an async chain). On the other hand (again this is something drawn from Eric's post) alongside async/await the framework team will add new APIs the Tasks API set, one of them being "multiplexing" of tasks (waiting for all tasks of a set of tasks, or any task of the set, although I'm sure the community has already implemented that separately)
[0] http://blogs.msdn.com/b/ericlippert/archive/tags/async/
Async/await is mostly a C#5 rather than .Net 4.5 thing. They could allow it to work against .Net 4 and even 3.5.
Not just could, but did: http://blogs.msdn.com/b/csharpfaq/archive/2012/04/26/async-t...
That's just the CTP, it's not clear yet whether they will release that support.
Async/await modeled after C# have been hacked into node.js as well:
https://github.com/koush/node/wiki/%22async%22-support-in-no...
https://github.com/koush/node/wiki/%22async%22-support-in-no...
Interesting- it looks a lot like tame.js, but integrated into V8 itself. I wonder what the performance benefits are.
The DLR + IronPython is some impressive and really useful stuff.
> 9. .NET Micro Framework – a version of the .NET Framework related to the Smart Personal Objects Technology initiative
What are those?
What are those?
Thats their framework you run on microprocessor platforms like Netduino.