.NET version 5, 6, 7, 8, 9, 10, 11, 12...

.NET version 5, 6, 7, 8, 9, 10, 11, 12... will we have a long... looong... looooooooooooooong list of .NET versions installed in Windows in the future? Somehow, I can't see it happen. Maybe they should unify this thing into one ".NET" and it should internally take care of versioning etc. and keep everything up to date.

What are you thoughts on it?

Hell no. .NET's side-by-side versioning is a practical solution to the problem. It only takes a brief look at configuration clusterf*** that is Java to see that relying on the runtime to stay internally compatible and then relying on users to configure multiple runtimes when that doesn't work out, is the road to disaster.

I expect the pace of development of the framework will slow down shortly, much like Java has. .NET (as a framework and language collection) leapfrogged Java in 2005 with v2.0, since then they've just been piling on more features than a single developer can master. I've been using the platform since late 2004 and I haven't found myself using any 3.0 or 3.5 features (besides C# language additions, none of which are truely dependent on the 3.0/3.5 framework).

VS2010 and .NET4 along with Windows 7 were big releases, so I'm not expecting anything major in the coming years. Maybe 2015 for the next stop in the roadmap, but even then I'm not expecting anything bigger than .NET Framework 4.5 or something.

Taking a long-term view of things, I see things stagnating about 7-8 years from now, such is what happened to COM and Java; and Microsoft will probably be thinking up their next Enterprise-development baby, hopefully with a better name. I see no reason why C# won't become the next VB6, as soon as the platform becomes inconvenient for Microsoft they'll drop it, leaving us: the developers, to pick up the pieces (and this is why there's lots of money to be had in VB6->CIL compilers).

In the medium-term, I expect XNA will become part of the BCL as Microsoft encourages more developers to drink the .NET kool-aid, they've already won over Enterprise devs, next on the list is game developers. Developing on XNA has the "Apple ObjC" advantage going for it: programs are impossible to port over to other platforms (at least until the Mono guys start).

...of course for Microsoft to win over more developers, they're going to have to tackle the two main drawbacks to the platform from a games' developers PoV: performance (and especially initialisation performance) and ease of disassembly. The Mono guys successfully developed a CIL-to-Native compiler for their MonoTouch product, I imagine Microsoft, too, would be working on something like this. Despite the arguments against it, I feel a native compiler for the .NET framework (coming from Microsoft) is the next logical step.

So in conclusion: I give the .NET Framework about another 10 years useful life before it's supplanted with something else and Microsoft to churn out more things that sit on top of an aging CLR.

W3bbo said:

I expect the pace of development of the framework will slow down shortly, much like Java has. .NET (as a framework and language collection) leapfrogged Java in 2005 with v2.0, since then they've just been piling on more features than a single developer can master. I've been using the platform since late 2004 and I haven't found myself using any 3.0 or 3.5 features (besides C# language additions, none of which are truely dependent on the 3.0/3.5 framework).

 

VS2010 and .NET4 along with Windows 7 were big releases, so I'm not expecting anything major in the coming years. Maybe 2015 for the next stop in the roadmap, but even then I'm not expecting anything bigger than .NET Framework 4.5 or something.

 

Taking a long-term view of things, I see things stagnating about 7-8 years from now, such is what happened to COM and Java; and Microsoft will probably be thinking up their next Enterprise-development baby, hopefully with a better name. I see no reason why C# won't become the next VB6, as soon as the platform becomes inconvenient for Microsoft they'll drop it, leaving us: the developers, to pick up the pieces (and this is why there's lots of money to be had in VB6->CIL compilers).

 

In the medium-term, I expect XNA will become part of the BCL as Microsoft encourages more developers to drink the .NET kool-aid, they've already won over Enterprise devs, next on the list is game developers. Developing on XNA has the "Apple ObjC" advantage going for it: programs are impossible to port over to other platforms (at least until the Mono guys start).

 

...of course for Microsoft to win over more developers, they're going to have to tackle the two main drawbacks to the platform from a games' developers PoV: performance (and especially initialisation performance) and ease of disassembly. The Mono guys successfully developed a CIL-to-Native compiler for their MonoTouch product, I imagine Microsoft, too, would be working on something like this. Despite the arguments against it, I feel a native compiler for the .NET framework (coming from Microsoft) is the next logical step.

 

So in conclusion: I give the .NET Framework about another 10 years useful life before it's supplanted with something else and Microsoft to churn out more things that sit on top of an aging CLR.

Uhh, .NET is natively compiled, on x86, x64, ARM, and PowerPC.

CreamFilling512 said:

W3bbo said:

*snip*

Uhh, .NET is natively compiled, on x86, x64, ARM, and PowerPC.

Yes, starting from .NET v2, all .NET runnables are compiled as native assembly in the installation process. (So you have .NET runtime optimization service NGEN in your service list.)

Just see how it runs like crazy when you just completed the installation of SQL2008...

======

Side by side versioning is a good thing, as that is always breaking changes in the next version (if not built on top of previous one like .NET 3.x)

Merging them into single runtime will just make the whole thing complex and unmaintainable, plus you end up installing much much more than you actually needed. That's bad for everyone.

======

As for foreseeing the future, I'd bet Microsoft will be throwing more people in F#, to make it easier to build high performance applications running on multicore processors.

Seeing Microsoft has a provision that CPU might grow to 32-cores from the processor affinity flag, it makes sense that they'd make the processor more optimized to seperate the load on multi-cores. (Seems our current compilers can spread loading to 2 cores, barely capable of spreading loading to 4 cores, but can't utilize more unless you really programmed for that.)

W3bbo said:

I expect the pace of development of the framework will slow down shortly, much like Java has. .NET (as a framework and language collection) leapfrogged Java in 2005 with v2.0, since then they've just been piling on more features than a single developer can master. I've been using the platform since late 2004 and I haven't found myself using any 3.0 or 3.5 features (besides C# language additions, none of which are truely dependent on the 3.0/3.5 framework).

 

VS2010 and .NET4 along with Windows 7 were big releases, so I'm not expecting anything major in the coming years. Maybe 2015 for the next stop in the roadmap, but even then I'm not expecting anything bigger than .NET Framework 4.5 or something.

 

Taking a long-term view of things, I see things stagnating about 7-8 years from now, such is what happened to COM and Java; and Microsoft will probably be thinking up their next Enterprise-development baby, hopefully with a better name. I see no reason why C# won't become the next VB6, as soon as the platform becomes inconvenient for Microsoft they'll drop it, leaving us: the developers, to pick up the pieces (and this is why there's lots of money to be had in VB6->CIL compilers).

 

In the medium-term, I expect XNA will become part of the BCL as Microsoft encourages more developers to drink the .NET kool-aid, they've already won over Enterprise devs, next on the list is game developers. Developing on XNA has the "Apple ObjC" advantage going for it: programs are impossible to port over to other platforms (at least until the Mono guys start).

 

...of course for Microsoft to win over more developers, they're going to have to tackle the two main drawbacks to the platform from a games' developers PoV: performance (and especially initialisation performance) and ease of disassembly. The Mono guys successfully developed a CIL-to-Native compiler for their MonoTouch product, I imagine Microsoft, too, would be working on something like this. Despite the arguments against it, I feel a native compiler for the .NET framework (coming from Microsoft) is the next logical step.

 

So in conclusion: I give the .NET Framework about another 10 years useful life before it's supplanted with something else and Microsoft to churn out more things that sit on top of an aging CLR.

No .NET Framework 3.0? So, you are not using LINQ? Here, take these 5 pity coins!

The .NET Framework will live on for a very long time with or without Microsoft involvement but given Microsoft history it is likely to be supported for a very long time to come.

That said, it's clear that some things are brewing in the background. Those things don't appear to have as much to do with the .NET Framework replacements as CLR alternatives as is witnessed by the Singularity RDK, the Bartok compiler, TAL compilation, Phoenix, etc. There's also some work going on to use Effect Typing, that is, declaring (tracking and constraining) the side-effects of functions which looks to be in line with previous Singularity research with stronger static typing (that these should be related is of course speculation on my part.)

And of course we don't know when or if these things will be relevant for the masses (that's us).

These efforts, however, along with efforts like Spur, do take on the performance issue. So that things like compute-intensive games, browsers and other low-level software become more attractive to write "in" {C,MS}IL[+]. This might one day annihilate all excuses for using C/C++ over C#(++) for high-performance computing from a pure performance point of view; that is not to say that there mightn't be other pragmatic reasons.

Along with increased run-time performance of code due to advances in compiler optimization, whether dynamic (JIT) or static (ahead of time), I expect to see ever more high-level languages from Microsoft as well as a continued refactoring and evolution of the .NET Framework to use these features. 

Side-by-side? No more necessary with static compilation.

So in conclusion, I believe your doomsday prophesies are quite misguided. There is a long and fruitful road ahead for the .NET Framework. Rejoice!

Ion Todirel said:

CreamFilling512 said:

*snip*

The IL is jitted to x86, x64 etc., yes. But CLR is not compiled for ARM or PowerPC, not that one which comes with .NET Framework. Nor the native side of the BCL, the JIT compiler or other parts of the (.NET) framework.

XNA on Xbox360 definitely JIT compiles PowerPC code, you can actually profile the time spent in the compiler.  I'm assuming it JIT compiles ARM code on mobile devices because that runtime is much more optimized than the Xbox PowerPC one.  This is actually the .NET Compact Framework though.

CreamFilling512 said:

W3bbo said:

*snip*

Uhh, .NET is natively compiled, on x86, x64, ARM, and PowerPC.

If you read my post, you'd see I was talking about a "traditional" compiler for CIL that ran on the developer's machine, not the end-user, so all that's distributed is a machine-specific binary and not a CIL assembly.

I don't think it'll be much of a problem. .Net is "mostly" backwards compatible anyway. How many machines do you still see nowadays with .Net 1.0 and 1.1 on it? .Net 3.0 and 3.5 don't really count because they were supersets of .Net 2.0 using the same version of the CLR. That means that .Net 2.0 has lasted us nearly 5 years.

I expect that by the time they're ready to really update the CLR again (as they've now done with .Net 4), .Net 2/3/3.5 will be almost as rare to find installed as .Net 1.x is now.

Sven Groot said:

I don't think it'll be much of a problem. .Net is "mostly" backwards compatible anyway. How many machines do you still see nowadays with .Net 1.0 and 1.1 on it? .Net 3.0 and 3.5 don't really count because they were supersets of .Net 2.0 using the same version of the CLR. That means that .Net 2.0 has lasted us nearly 5 years.

 

I expect that by the time they're ready to really update the CLR again (as they've now done with .Net 4), .Net 2/3/3.5 will be almost as rare to find installed as .Net 1.x is now.

Yeah.

Thing is, I did not suggest to make it all as "one ", just make it look like one. Ease of use. The .NET installer should be intelligent enough to know all this and update itself and add newer versions etc. imho. WHY would anyone NOT want .NET 4 installed for example? ( Speaking of regular Windows PCs out there. ) They all have already 1.x 2.x 3.x. It just creates headaches chasing installed versions all over the place on users' PCs.

To make things even harder, .NET doesn't show up as high prio I think and only optional. :E Since all the .NET versions are already separate, it won't harm the end user to install them all. If the user already made a choice of getting .NET 1.x, then all other versions should be in there automatically.

Being in Windows world where usability is everything for "joe the moron" so to speak...

The user should only and only have to know one thing : Do I have .NET installed or not.

Nothing more, nothing less.

EDIT : Real life example : I got a .NET 3.x application which will now be compiled to .NET 4.x. I must run around like a chicken without a head and chase the users to install .NET 4 because once they get the new application update, "it'll break". Surely I could do it differently with installer etc. but I shouldn't have to. If the user has .NET, then Microsoft should make sure the user have ALL versions of .NET at all times. ( Since the user already made an active choice of getting and having .NET in the first place. )

Ion Todirel said:

turrican said:

*snip*

> Real life example : I got a .NET 3.x application which will now be compiled to .NET 4.x. I must run around like a chicken without a head and chase the users to install .NET 4 because once they get the new application update, "it'll break".

 

Are you using any .NET 4.0 specific features? If not, you can have your app targeting 3.5 and it can run on both 3.5 and 4.0.

Ya, I know, and I don't use any .NET 4 features... yet. But... I have a policy to always upgrade, no matter what. This way I won't be stuck with a floppy drive and no floppy disks to buy so to speak.

In my humble opinion, software ( and hardware ) is not like wine, older isn't better. So I do my best to keep upgrading otherwise, I'll be like some of the people I know sitting on Windows XP bitching about how 1GB RAM is not enough for them. hehhe... That kind of thing is not acceptable in my world. This is what usually say to my users : New .NET came out? Get it! New Windows 7? Get it!

Ok, Vista is an exception... that proves the rule.

EDIT : Heck, I know some high up IT people who... believe it or not... DOES NOT KNOW WHAT Silverlight IS!!! Now THAT is creepy.

turrican said:

Ion Todirel said:

*snip*

Ya, I know, and I don't use any .NET 4 features... yet. But... I have a policy to always upgrade, no matter what. This way I won't be stuck with a floppy drive and no floppy disks to buy so to speak.

 

In my humble opinion, software ( and hardware ) is not like wine, older isn't better. So I do my best to keep upgrading otherwise, I'll be like some of the people I know sitting on Windows XP bitching about how 1GB RAM is not enough for them. hehhe... That kind of thing is not acceptable in my world. This is what usually say to my users : New .NET came out? Get it! New Windows 7? Get it!

 

Ok, Vista is an exception... that proves the rule.

 

EDIT : Heck, I know some high up IT people who... believe it or not... DOES NOT KNOW WHAT Silverlight IS!!! Now THAT is creepy.

not creepy, normal.

back in about 2004 i did some work where it took about 3-4 weeks to get some corp. it folks to install .net 1.1 on 3 pc's

i had to explain what it was and why it was ok. i had to compare it with java - they had java running a special app there.

and i had to explain that it was safer than a raw native app due to the way .net workes.

a lot of it that is done for corp. networks is about keeping things going w/o spending any more money than is in the budget. anything that they see as "new" is handled like radioactive waste.... untill the learn it's ok.

figuerres said:

turrican said:

*snip*

not creepy, normal.

 

back in about 2004 i did some work where it took about 3-4 weeks to get some corp. it folks to install .net 1.1 on 3 pc's

i had to explain what it was and why it was ok. i had to compare it with java - they had java running a special app there.

and i had to explain that it was safer than a raw native app due to the way .net workes.

 

a lot of it that is done for corp. networks is about keeping things going w/o spending any more money than is in the budget. anything that they see as "new" is handled like radioactive waste.... untill the learn it's ok.

Yes I suppose you are right, I mean, I can see how they don't want to install new stuff on their machines.

But not knowing what .NET or Silverlight even is for an IT administrator is just creepy. They shouldn't be in this field if they never heard of Silverlight or .NET. The whole thing about IT is that we need to educate ourselves about new stuff coming out or we will be obsolete in the work place since the knowledge is too old because of the fact that IT moves forward so fast.

turrican said:

figuerres said:

*snip*

Yes I suppose you are right, I mean, I can see how they don't want to install new stuff on their machines.

 

But not knowing what .NET or Silverlight even is for an IT administrator is just creepy. They shouldn't be in this field if they never heard of Silverlight or .NET. The whole thing about IT is that we need to educate ourselves about new stuff coming out or we will be obsolete in the work place since the knowledge is too old because of the fact that IT moves forward so fast.

I can see you don't work in IT. Most of the people here have been here since the early 80s and have no motivation to learn new tech. It can be very frustrating.

spivonious said:

turrican said:

*snip*

I can see you don't work in IT. Most of the people here have been here since the early 80s and have no motivation to learn new tech. It can be very frustrating.

I have been in "IT" since the early 90s but unlike others, I do work hard to not be "left behind". You just prove my point.

If a person lacks enough motivation to know his job, then that person is no longer fit to keep that job. It sure can be frustrating, but are you suggesting being in IT since the 80s and lacking motivation is justifying an IT administrator to not know what .NET or Silverlight is? Not saying know how they are built and decompile them but a general idéa of what the heck those things are is needed to be an IT admin, no? or atleast should be.

Come'on, what you say doesn't sound right at all. We are not doing cooking where you use the same recipe for 40 years, even those recipes change.

Imagine if doctors didn't learn the new drugs and medical stuff coming out and would still be using stuff that are now known to be harmful from the 70s? Imagine if dentists did the same? I disagree with you that being old, without motivation and since it is frustrating, is excuse to not know your job.

Maybe that's why some admins still love Windows NT 4 or 2000?

Sure, I agree that it IS hard and it IS frustrating... for example...

When I had to leave Delphi and jump to C#...

When I had to leave DOS and jump into Windows...

When I had to leave doing ASM and jump into Pascal...

When I had to leave my AMIGA to jump into PC...

When I had to leave my ATARI STFM to jump into AMIGA...

When I had to leave my C64 to jump into ATARI...

By that standards which you suggest, I would still be using a C64! ( not that I wouldn't mind using one now hehhe )

10 years from now, maybe we won't be having C# or .NET either and something new has come out... should we still be attached to C# and not learn the new thing? I say no. Eventhough it's hard and not all people can do it.

If you want to be good at your job and on what you do, you must be evolving in terms of educating yourself all the time. After all what someone learned in university 20 years ago might no longer apply.