HN Explorer

.NET Framework Version Comparision (jinaldesai.net)

56 points by peaceison ↗ HN
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.

55 comments

[ 4.1 ms ] story [ 109 ms ] thread
fosk
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.
Gjallarson
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.
gouranga
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).
TazeTSchnitzel
I thought .NET types were optionally nullable? I don't think they are by default.
gouranga
They are optionally nullable. Unfortunately, people seem to think that making use of them everywhere is cool :(
NetMonkey
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.

DrJokepu
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.)

tomjen3
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.
gouranga
That would be fantastic - great idea!

No More:

   Check.IsNotNull(objRef, "stop being a muppet");
bunderbunder
.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?

soc88
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
bunderbunder
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.
soc88
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.

Djehngo
For what it's worth 4.0 also added co-variant and contra-variant generics which are surprisingly useful.
gouranga
I've written about 400kloc in C# 4.0 and I haven't had a need yet :(
Yrlec
How is that ironic?
profquail
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).
boyter
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.

masklinn
> 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.

[dead] innes
That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue.

Yes, but this is the relatively easy bit. It's writing comprehensible code around and about that underlying async operation that is the hard bit.

Ultimately, `async` and `await` still are nothing but sugar over the Tasks API.

The tone here implies that sugar is not an important thing in programming languages. These keywords do a great deal for you, under the bonnet. Everything is 'sugar over the assembly language API'.

[dead] andersh
That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue.

Yes, but this is the relatively easy bit. It's writing comprehensible code around and about that underlying async operation (such as a file read) that is the messy part.

Ultimately, `async` and `await` still are nothing but sugar over the Tasks API.

The tone here implies that sugar is not an important thing in programming languages. These keywords do a great deal for you, under the bonnet. After all, everything is 'sugar on top of machine code'.

[dead] 4deadaccounts
That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue.

Yes, but this is the relatively easy bit. It's writing comprehensible code around and about that underlying async operation (such as a file read) that is the messy part.

Ultimately, `async` and `await` still are nothing but sugar over the Tasks API.

The tone here implies that sugar is not an important thing in programming languages. These keywords do a great deal for you, under the bonnet. After all, everything is 'sugar on top of machine code'.

vyrotek
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.

masklinn
> 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/

jinushaun
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.
[deleted]
(comment deleted)
hamidpalo
What is "enterprisey" about .NET?

Mono is a real alternative, many businesses run it production, including the likes of Fog Creek.

TazeTSchnitzel
.NET is very "enterprisey". It seems to be designed to make creating line-of-business applications easier.
[dead] 4deadaccounts
I'm sorry, but throwing around vague pejoratives like 'enterprisey' is lazy as hell. Please formulate an actual argument.
hamidpalo
What exactly makes it enterprisey? I am always really unclear on what makes something "enterprisey" other than perceptions.
powertower
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.
hamidpalo
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.

jinushaun
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.

gecko
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.
hamidpalo
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]
(comment deleted)
yatendra
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.
rbanffy
> 9. .NET Micro Framework – a version of the .NET Framework related to the Smart Personal Objects Technology initiative

What are those?

locusm
Thats their framework you run on microprocessor platforms like Netduino.
phoboslab
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-...

jaredsohn
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.
ses4j
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.
tomjen3
C# needs to be decoupled from MS. It is too cool a language to be tied up with windows.
bunderbunder
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.

jinushaun
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.
saryant
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.

dozy
The DLR + IronPython is some impressive and really useful stuff.