Post a Comment
I like how he is talking about 3.0 when 3.5 has been out since last december ;-)
He has a point though. Most people doing gui apps are still on 2.0, because it will already be on every xp machine. I guess "vista" applications are going to be when people start standardizing on 3.0.
Of course, where I work we are just finishing up the migration to 2008 and 3.5, and the whole company is on vista business machines with office 2k7, so I have a bit of a distorted view of such things.
Because .NET 3.0 is just a marketing thing... It's basically 2.0 with some added libraries. For someone writing Winforms-based .NET apps, there's very little reason to target 3.0 when 2.0 has all the same functionality that they need.
As for 3.5 - I wouldn't know, I really haven't even looked at it yet.
Well, those libraries were huge. Winforms, asmx's, and remoting all got deprecated by completely new technologies. The C# 3.0 language stuff around LINQ was also a big change, I have been using it since it came out and I am still wrapping my head around things like extension methods, lambdas, and linq expressions.
I would say that 3.5 was more of a marketing release then 3.0 was. 3.5 sp1 has at least as much new functionality as 3.5 rtm had.
You are confused... Linq was part of 3.5, 3.0 added WPF, WWF, WCF, and cardspace.
http://en.wikipedia.org/wiki/.NET_Framework#.NET_Framework_3.0
I didn't really say that either. But it is a big thing in the .net world. What (IMO) is a bigger deal is the whole lambda thing, being able to pass in an anonymous function, and have it be treated as an expression tree at the other end is basically a functional language thing. Extension methods is another really cool C# 3.0 thing, basically like open classes in ruby.
How long was 2.0 out for? A quick Google search reveals that it was released in November 2005. When was 3.0 released? November 2006. 3.0 deprecated Winforms with the introduction of WPF which is so radically different from Winforms that it will require a complete rewrite of the GUI.
Such large changes in APIs are never a good thing as it takes a very very long time for applications to be rewritten. Consider the move that the KDE project made from Qt 3 to Qt 4. Qt 4 made quite a few changes to the Qt library that made it incompatible with Qt 3. Nevertheless, a tool was made available to automatically port Qt 3 code to Qt 4. Even so, it still took 3 years for KDE to make the move to Qt 4, Qt 4 first appeared in June 2005 and KDE 4 appeared in January 2008 (ignoring betas, RCs, etc for both projects).
The jump from Winforms to WPF is considerably larger as WPF is nothing like Winforms. Not only is WPF considerably different from Winforms, there is the issue of support to consider. How long is Microsoft going to support WPF? Winforms was introduced in 2002 with .NET 1.0 and it was deprecated 4 years later. Not even Apple does that to their APIs! Compare that with MFC/Win32/ATL/WTL which has been fairly stable for the last two decades. Any sane project manager is going to take the wait and see approach with WPF to see how things develop. Will WPF be the new MFC? Or will it be deprecated in 2010 in favor of whatever new and cool stuff Windows 7 is going to bring?
Then you have the performance issue. Many applications cannot afford the runtime performance penalty that the .NET framework incurs. Sure, it works for in-house applications, the niche that VB 6 filled but it's just not suitable for most client side software that home users run. If given the choice between a .NET managed app and an unmanaged native app, you can bet users will flock to the unmanaged native app. See Beagle -> Tracker for an example.
TLDR version for you guys with ADHD:
1) WPF is too different from Winforms.
2) Winforms support was too short (at 4 years). How long is WPF going to be supported for?
3) .NET performance is still not up to par with managed code. It may not matter for some applications, but it matters for many others.
We knew that winforms wasn't here to stay pretty much from 1.0 when we were first hearing about the vista presentation stuff.
I really get the impression you haven't tried WPF yet. Winforms was more a stopgap then anything else, its more or less a wrapper around the old MFC way of doing things with a bit of sugar here and there. WPF is a completely new paradigm, and as a web guy it is the first client gui API I have seen that made me considering shifting off of the web.
The vast majority of windows development is in-house apps ;-) You are right, but the segment you are talking about is stuff like photoshop, office, 3DSmax, etc. That is only a very small percentage of the industry.
It should be pointed out that KDE4 isn't simply a port of KDE3 to Qt4. It was a complete rewrite of all the underlying libraries, the addition of several new core libraries and a complete redesign of how the KDE desktop works. I imagine the actual Qt3 to Qt4 work was a tiny part of the total work done.
None of my friends or family have XP machines with either .NET 1.1 or 2.0 installed. There simply aren't any .NET apps that any of them feel compelled to use. I have never installed .NET for them, and they have never required it.
I had to update several apps to run properly on Vista.
Citrix Management Console (4.0 and 4.5) doesn't work properly.
More importantly, Microsoft's own Windows Server 2003 Administration Tools Pack STILL doesn't work without a patch.
Most of the App gap is either older application, such as Visual Studio 2003 (funny to me), or hardware-related applications such as TV card players, etc. The former can be resolved using VirtualPC and an XP license. Not much you can do about the latter.
On the other hand, I still struggle with newer applications like Komodo and PHP. Vista keeps giving wierd errors about the PHP executable not terminating correctly (every second or two!). In addition, many of my applications require (or strongly recommend) that I install them in a folder besides "Program Files", which has extra OS protection. If seems wierd to go back to the Win 3.1 days of c:\MyApp. Of course, many will lay the blame for that on the ISV's. As an end user, that makes me feel all warm inside, NOT!
Funny thing, I have to support an old PHP app I inherited, and i have no issues running PHP under fastcgi with IIS7 ;-)
Actually, think PHP as an ISAPI module would work fine on Vista. I think the actual problem is the integration of Komodo (my IDE) and PHP. Komodo is using the CLI version of PHP to interact with PHP. It is the command-line version of PHP that is having the problem - I imagine the way it terminates (who knows, maybe it doesn't return 0 at the end of main!) causes the problem. Komodo is constantly running the PHP CLI executable, and thus I get a popup-message every second or two about the improper termination of CLI.exe. For me it isn't a big deal - I just use Komodo under Linux. I rarely have to boot into Vista anymore. My only use for Windows is gaming (although many games do run under Wine now), but I keep an XP box around for that.
"The real question should be: Why aren't developers leveraging the various iterations of the .Net framework?"
When the parent company who designed the technology isn't fully embracing it, it doesn't leave much confidence to third parties as to the long term nature of it. I would have expected by now, quite frankly, Microsoft to be announcing that Office 14 would be .NET 3.5 Native (using managed C++ and C, along with some C# thrown in for good measure). I expected Microsoft to have thrown off VB 'classic' in favour of .NET languages being used instead.
None of this has happened, and here we are, over a year since Windows Vista was launched, and still no Microsoft applications that are 100% .NET native.
It isn't the technology, but the fact that you're not using the technology that tells the rest of the IT world that .NET isn't ready for big applications - its only useful for dinky little widgets custom requirements in large companies.
If you are somehow on top of technology and have some ability as a technical professional pushing .NET apps is just silly. For custom business applications the way to go is web based, using AJAX and dynamic HTML you can create applications that do what needs to be done and not worry about issues such as distribution, compatibility across different Operating Systems and versions, Users will always use the correct version of the software, ability to access from remote locations (and non-company) computers via VPN or Internet connection.
The tradeoff between web apps and normal apps are so small now for most applications that making it OS Particular will take the same amount of development time and loose out on lot of the features inherent with Web Applications.
While you can use .NET to make these web apps however you don't need to stick with it, nor will your costumers really care. PHP, Ruby On Rails... People can use the apps without caring what your server is.
I think you're kind of missing the point of the article, though. One of the things that makes a new operating system interesting is what new applications are being written for it -- and how those new applications leverage new features in the OS. I'll grant you that features in client operating systems have diminished in importance as much of the infrastructure moves to servers; however, to paraphrase Bill Clinton (I try to do that as little as possible), the client OS isn't dead or insignificant yet. And that's kind of why we're here.
Edited 2008-06-24 23:46 UTC
I didn't take advantage of WPF nor LINQ since there really wasn't any advantage for what I wanted to create. Just one disadvantage, user must have 3.5 .NET runtime installed (for LINQ, 3.5 is required).
Vista's bad press made me think twice, and it was already a gamble...assuming people had .NET 2.0 runtime. It's like Java, are you willing to force people to download a runtime or take the risk and target only those who have it installed.
Edited 2008-06-25 06:55 UTC



