Submitted by “Last week at the BUILD conference, we had the pleasure of announcing the next version of the .NET Framework and releasing a developer preview at the same time. We have so many new things in .NET 4.5 to discuss with our developer community – we’re excited to have this opportunity to begin a discussion about each of them.”
Who freaking cares? Dot NET started off as a good idea implemented horribly from the get-go. Maybe it has matured as it should have but the lack of built-in backwards compatibility frustrates me as an end-user. Having to load 1.1, 2.0, and 3.5 all together in XP left me frustrated at all the code bloat.
Sorry, had to fume a bit. I’m OK now.
More to the point, Windows 8 seems like a clusterf**k of APIs and frameworks. Apparently, WinRT/Metro is supposed to be the big new thing, and now they’re updating .NET with improvements to WPF, and the ability to build Metro-style apps with .NET. Wait, weren’t developers supposed to use WinRT for that?
Here’s what WinRT did to .NET: All the foundational classes (Collections, Threading, etc.) plus all of the Win32 wrappers were jettisoned from .NET proper. They were replaced by WinRT components (which are really COM components with .NET friendly wrappers autogenerated from .NET metadata which WinRT components emit)
The only thing that still remains in the BCL are things which make sense exclusively to .NET, and not to anything else. Any class library which can be shared across C++ or JavaScript has been rewritten in native code and put into a WinRT component.
Its why for example C# XAML and C++ XAML Metro applications have unified binding interfaces, so your business layer in C# could be exposed via WinRT.
As for their Desktop strategy (Relating to Silverlight, WPF, and .NET 4.5) its so confusing that I’ve lost all hope they’ll ever sort that mess out.
There’s .NET 4.5 and WPF, there’s Silverlight (which is frustratingly, subtly different from WPF, and includes its own .NET CLR with its own quirks), there’s good ol’ WinForms, and now there’s WinRT with C#/XAML (which is different from both Silverlight AND WPF AND has its own subtle quirks).
As a developer, this is a clusterfuck. WinRT is really what .NET should always have been, its really well designed and very fast, but I mean damn, that’s a lot of legacy bullshit to be lugging around.
Please..
Where I work, we use .NET 3.5 and 4.0 (for WPF and ASP.NET apps) and then Silverlight 3 and 4. Guess what, it’s not a problem at all.
Quite the opposite, you use C# all the time and in cases of SL and WPF you use XAML. Are there some differences, yes, but trust me, it’s not worth talking about.
Big deal is, you don’t have to learn a completely new technology (language, framework, etc) to create different categories of apps (web, desktop, phone, service).
WinRT is going to be just another similar technology that we will adapt. And most of my peers are looking forward to it, why shouldn’t we? We can again just learn a thing or two that is new/different and we’re ready to go..
You don’t know the power of the dark side 😉
Edited 2011-09-24 23:09 UTC
Actually, they are worth talking about, so lets talk about them.
There has been a 70 page (!) whitepaper posted on the differences between WPF and Silverlight. I personally have had to deal with these subtle and frustrating differences.
For example, the entire Silverlight rendering pipeline is different from WPF. Things that were perf wins in WPF, are perf losses in Silverlight. For example, extensive use of effects in Silverlight are very detrimental to framerate because the HLSL shaders are actually interpreted and rendered in software to achieve maximum portability across platforms.
Whats worse is Silverlight for Windows Phone is a weird Frankenstein Silverlight 3/4 mashup, along with a Compositor thread.
Silverlight 5 finally gets the compositor thread, as does WinRT. WPF4.5 does NOT.
Ever tried to do touch on WPF/SL/SL for Windows Phone/WinRT? It is different for ALL of them. For EVERY SINGLE one it is a different implementation. Its fucking annoying.
WPF (prior to v4) has either no, or an incompatible implementation of the Visual State Manager, and Silverlight has very rudimentary Trigger support.
Same goes for things like perspective transforms and bitmap caching. Silverlight has both of these, and WPF has neither (actually the former was fixed in WPF4).
The XAML parser is different, so support for direct content in anything but SL4/5 is a pain in the ass, the same with ignoring whitespace. XAML in WPF is compiled to a binary representation, while in Silverlight its interpreted on the fly, leading to a less than stellar parsing performance, and a less sophisticated error reporting subsystem (Ever get a cryptic AG_PARSER_E message? Welcome to hell.)
How about all of the random data template and binding issues which leak in WPF but not in Silverlight (and vice versa?) Where is my OneWayToSource binding in Silverlight? Its been like 3 years guuys.
Silverlight lacks a lot of what makes the WPF pipeline extensible, like control over the layout pass via layout transforms, and it breaks a shitload of code and makes nontrivial things in WPF, a living hell in Silverlight.
Dont get me started on the POINTLESS, NEEDLESS and SILLY method signature differences between (get this):
Silverlight, Silverlight for Windows Phone, WPF, and WinRT/XAML for dependency properties. ALL of them do it SLIGHTLY differently. Your code ends up being a mess of #ifdefs . Its even worse in WinRT where they pointlessly changed nearly every fucking namespace in the framework for no reason.
Lack of tunneling events in Silverlight? Means throw away half of your old WPF input infrastructure.
Hell, while we’re on input, do you realize that until Silverlight 4, something as basic as ICommand and Command Bindings were NON EXISTANT?
Silverlight until 5 (which will be released god knows when) has no custom markup extension support, no DataContextChanged support, and probably will never get pixel rendering parity with WPF4’s font renderer. Fonts in Silverlight are a fucking disaster.
Ever try to traverse the VisualTree in Silverlight? Oh, yeah, those hundreds of lines of code you wrote manipulating the Visual Tree for WPF, none of it cross compiles. Which on the face of it, is entirely fucking pointless anyway since even neutral WPF libs need a recompile for Silverlight.
The fragmentation is annoying as hell for maintaining any kind of reasonably sized project across both platforms. Porting is a living hell.
This is just a few I can think of, but clearly, clearly, this is a lot less trivial than you make it out to be.
The point was that all of these technologies are supported going forward, with their wild inconsistencies, it makes the platform into one big mess.
The main scenario will be probably Windows Phone apps and Windows 8 apps. The sad thing is that they both run two wildly different platforms (as I’ve shown above) with different performance characteristics..
Its not just UI stuff that doesn’t carry over, thats a given, you’d rewrite your XAML anyway. Its fundamental rendering issues, binding issues, hell everything.
I know that we here don’t have any problems using those technologies at the same time. Are there differences? Yes, but so what? Those aren’t that big.
Just compare, for example, going WPF->Flash vs WPF->Silverlight. Are you kidding?
If you know WPF, you shoud not have ANY problems working with Silverlight or WP7. And you should not have any trouble doing Metro apps. Will you have to learn a bit here and there? Yes. But you can still reuse practically all your XAML/C#/.NET knowledge. And that, my spoiled friend, is a big f*****g deal, as vice Biden said recently
Man up already.
LOL
Hell, while we’re on input, do you realize that until Silverlight 4, something as basic as ICommand and Command Bindings were NON EXISTANT?
But you do have that now, don’t you??!!! Just like WPF 4 has VisualStateManager, etc. Doesn’t precisely that prove that you’re wrong? It does.
(Do you have those in ActionScript? Do you? When will you get them?)
Anyway, use MVVM Light and you’ll thank me.
That’s just one (of many) frustrations. Its only a symptom of a deeper problem, which is that two completely separate codebases try to achieve some semblance of parity and fail horribly at it.
You have two parsers, with two rendering engines and binding engines each with their own set of quirks and bugs, and expect to have an easy time porting software that’s even a little bit complex? I’m not talking about MyFirstEnterpriseApp, I’m talking about complicated N-tier LOB applications with LOC numbers that lock up Visual Studio.
Try migrating that. I’ll reiterate my original point again, that its not so much that its hard to port (but believe me, it is hard to port especially going from WPF -> Silverlight.), but that the Desktop toolkits have no sense of direction.
Is WPF dead? Is Silverlight dead? If Silverlight is being relegated to LOB then it will be cannibalizing its brother WPF (which is much better suited for it, minus the deployability). Do either of these technologies have a future in our brave, new WinRT world?
Sure, today, tomorrow, maybe even a year or two from now they will still be here, but will there be a Silverlight 6, or a WPF 5?
Silverlight had great potential but was a monumentally poorly executed idea. WPF was too overengineered and ahead of its time. WinRT is just right, but Microsoft now has the burden of two similar (but incompatible) alternate implementations of the same core technology.
BTW: Other platforms being worse off than the Microsoft stack is not a valid defense of the sad state of affairs. .NET and the Microsoft Stack is supposed to be better than this.
Who would’ve thought I’d see the day when the big bad WPF platform was killed off and replaced with an alternative which plays second string to fucking HTML5.
So enjoy your
#ifdef !SILVERLIGHT && !WINRT
#else
#endif
and weep that XAML has no conditional compilation.
Try migrating that.
Why would I?
Even if I did, I’d still be working with XAML and C#. And similar (if not the same) interfaces, etc.
Try migrating that (WPF) to Flash and come back to tell me how much you had to learn.
How much you DON’T have to learn when going (not necessarily migrating, but also just creating new app) from WPF to Silverlight or SL->WP7?? Beat that.
Microsoft now has the burden of two similar (but incompatible) alternate implementations of the same core technology.
As opposed to what.. having two 100% compatibile technologies?
Well, then it’s just one technology, is it not
Will SL and WPF be here 5 years from now? Yes. 10 years from now? Most likely. New versions? Maybe. Maybe not. So?
And if they don’t.. so what? We’ll switch to Metro and guess what, there will be A LOT that you already know, like XAML and C#.. You are focusing too much on what’s different rather than on what’s is not (so) different.
I don’t know that my wife will be with me a year from now
and I tend to trust her more than I trust MS. 10 years from now? LoL 
Just to add, at some point I plan to retire too 
I personally have had to deal with these subtle and frustrating differences.
Or.. you can try Flash, for example. Please do, then come back and tell us how many differences between WPF and Flash you found.
Hey, Java FX is another option you may want to compare.
THANK YOU. I tried to keep my original comments fairly spartan but legacy cruft is the point I attempted to make. Yes it is true that 3.5 maintains backwards compatibility back to 1.1 but it does it by inheriting all the bastard code bloat with it.
Dot NET is merely a reflection of what is wrong with Microsoft, you need only look at the events driving the MinWin initiative to grasp how lost MS is right now. Too little, too late.
You can put lipstick on a pig but it won’t get any prettier.
Yes, you can move along, but at the same time maintaining all the legacy code you left behind. In Software development, we know that the longest job of a programmer is software maintenance and update. Clipper, Foxpro for DOS, Foxpro for Win, VB6 are still heavily present among businesses.
And how precisely this would NOT be better?
Let’s say 5 years from now we’re all doing WinRT. So, you use XAML and C# and most likely full .NET on server side. And then you also have to maintain older WPF (or SL) apps. Well, again, it’s XAML and C# (and possibly full .NET on server side).
Compare that to maintaining older apps created in completely different techonologies, those that you mentioned, for example.
Well 3.5(and 3.0) was still CLR 2.0 so .NET3.5 is all you needed. 4.0 was the CLR change, and 4.5 runs onto of the CLR so 4.0 apps don’t need a side by side installation.
Other than you only really need 1.1 and 3.5 … is having a few megabytes of software library code that bigger deal?
Edited 2011-09-24 08:39 UTC
You need 1.1 to run 1.x code. 3.5 supports 2.0 and 3.x. You can use 1.1 assemblies in 3.5 apps so long as 1.1 clr is installed. So, your assertions on backwards compatibility are both wrong and badly informed. We still have some Winforms apps migrated to 3.5 that use 1.1 components, as the components were discontinued.
Wait…. all .net 2.0 applications will run in 3.5
1.1 is the only legacy version before 4.0 came out.
So, 1.1 is necessary for those really old applications, and then 3.5 and adding in 4.0 for new apps using the 4.0+ framework.
But yes… MS should package the legacy portions of the framework. It shouldn’t hurt anything if they engineered correctly.
is to kill .net and co-develop Mono for all platforms.
Actually. WinRT is a new software stack built on top of the winnt kernel, and .net is becoming into just a binding on top of it (with a lot of traction and commitment to native c++/cx metro apps); so, i do not see where mono would fit in this new ecosystem. Actually i like the winrt idea, but it is in fact a stepback for the .net world.
Mono should just run off an develop a system independent framework from the solid base they have and simply keep the CLR in sync.
C# devs want to write C# and as long as a CLR is available that provides the current language features, the framework they choose to work in can be as varied as the frameworks that are available for Java.
Unfortunately this has been suggested numerous times.
Miguel seems to be bent on copying the full .Net stack even though it does not fit logically across platforms. Mono continues to be a half-ass attempt because of this.
Best from which point of view ?
I care because .net 3.0 and .net 3.5 aren’t supported in wine yet.
I care because by not being supported in wine, most new games built on games for windows live don’t work in wine. It’s yet another hurdle for wine to work around, even though all of DirectX 9 is basically implemented, modern AAA gaming titles will still fail to run because of lack of compatibility with Microsoft’s .net frameworks.
I care because it means on Linux and OSX I still need a copy of Windows installed to run all of the games I have.
Edited 2011-09-25 12:07 UTC