I have to say, I'm not a fan on the adoption of the hated Windows style "R2" naming convention. It gets especially bad when you start talking about service packs which results in nightmares like "SQL Server 2008 R2 SP2". Yuck!
It's really quite sad that this poor naming convention means that you're going to miss out on the opportunity of having a "2010" titled product
Wow, the perf difference between beta 2 and previous builds is like night and day. I'm so glad Rico has been on the case - I'm not sure if anyone else could have pulled this off in quite the same way
If you're reading Rico, sorry to have previously given you such a hard time nagging about performance / features loss with the new shell. A lot of areas feel faster, and I'm really pleased that the switch to the WPF shell hasn't resulted in the loss of
any major features. In fact we've gained a number of great new editor features, and WPF itself has benefited from the whole dog fooding process.
On a side note, I like to have posted this on Rico's blog, but there seems to be an issue posting comments to all msdn blogs at the moment. Obviously some people's comments are getting through but I've spoken to a number of others who are completely unable
to post comments (roughly since the time the captchas were introduced). Can anyone look into this?
I would say using the right tool for the right job is the best solution. WinForms is still the best tool to use for creating applications that fit in with the look and feel of Windows. It's also much better suited to business type applications with great
RAD support for drag and drop data binding. WPF on the other hand is better suited to applications where the user interface IS the application and requires a UI outside the scope of standard Windows controls e.g. a family tree application where relationships
are displayed in a visual manner would obviously be best implemented in WPF.
When creating new applications, WinForms is still my preferred choice in most cases. If a situation does arise where a part of the application really needs some non-standard UI which is beyond the scope of the WinForms controls, then I would simply drag
and drop an ElementHost onto the form and link into some XAML. However, for the majority of business applications we write at the company I work for, there's no need for this at all - about 99% of the controls we need are already present in the framework
or through third party controls.
With WPF comes great power, but also great responsibility. I've seen some absolutely hideous WPF applications out there. At least with WinForms, you're pretty much guaranteed an interface that is fairly familiar to end users. Sure, WPF can have videos
on buttons, but what has that achieved you? Puzzled users usually! Plus, as the Windows themes evolve over the years, will your polka dot splattered WPF application still look modern?
Don't get me wrong, the declarative WPF approach is definitely the correct direction to aim in. It's just that WPF has so many negative points, that's it's just not worth moving to until all the productivity draining issues have been sorted out. It does
seem to be improving, but it's at an excruciatingly slow pace. For example it's pretty hard to believe that it was only November last year that WPF finally got support for double clicking elements in the designer in order to automatically hook up events!
It's just not worth investing in WPF until Microsoft get their arse in gear and get the major WPF issues sorted out.
Other reasons for not using WPF include:
Poor WPF design time experience - too much focus on XAML and not enough on the designer. My goal isn't to write XAML, it's to create an interface, and anything else is a productivity draining distraction.
In order to create even a half decent UI you're going to need to hire a professional designer. Not every company has the resources for this. This also involves the additional purchase of Blend.
There is still no built in data grid (unbelievable!). Yes I know one is in development on CodePlex, but that doesn't count as it isn't even finished, and it needs to be something built into the product to be viable.
Too much plumbing work e.g. manually hooking up bindings in XAML using bizarre syntaxes. It's not fixed yet, but it's great this is partially being addressed in .NET 4. Then there's all the nonsense with dealing with resources at just about every step.
We shouldn't have to worry about all this plumbing work - it's like going back to the dark ages.
The built in dialogs don't even support windows themes. Try doing a MessageBox.Show and look at the Windows 95 button!
Property grids in the designer are simplistic and unhelpful (i.e. just a text field to pick a color!!!). Again, thank goodness we're getting a color picker in .NET 4. Is it really progress to be excited about getting something we've had for years in WinForms?
Total lack help in the designers - e.g. no help tips in the XAML window and no help text at the bottom of the properties window.
Non-standard look and feel. By default a WPF app does not conform to the Windows color scheme. In fact it looks more like a Windows 3.1 application with its default white background. We learned the "consistent look and feel" rule DECADES ago. For the
most part developers DO NOT want to reinvent the wheel UI wise for every app they write. We want consistency with the Windows theme, or at a stretch, parity with the latest Office look and feel. But users want it globally, not a hundred different UI's and
controls for each different app.
Performance issues, especially on slower machines e.g. start up speed. Is everyone happy with the performance issues with Visual Studio 2010 now that it's WPF based? Hell NO!
Absolutely pathetic text rendering quality. This has been bugged on Connect and sat there ignored for YEARS. At least this is finally on the cards to be looked at in .NET 4 beta 2.
At least there is a glimmer of hope of some improvements in .NET 4, especially now that MSFT are dog fooding WPF in Visual Studio 2010 and they're finally getting a taste of the pain points of developing a real world application in WPF. According to Microsoft
themselves, WPF issues have set the VS2010 schedule back by months.
For now, I think I'll stick with WinForms thanks. In the meantime, I'll certainly be keeping an eye on the progress of WPF. Hopefully one day it will actually be a feasible and productive technology to use in the real world.
I really don't think keeping the two languages in lock step is a good idea. It’s only going to hinder the advancement of both languages. Having a bit of competition between VB and C# is actually a good thing. For example VB might never have got XML literals
if it had to wait on C#. As long as the two languages can access and export the same libraries, I’d rather they had the freedom to explore their own avenues.
As for VB vs. C# usage being 50/50, I don’t think this is the case. I know from some previous surveys the results have been skewed due to Office VBA “developers” (hehehe) taking part in the surveys. Regardless, all the surveys I’ve seen recently are pointing
to massive declines in VB usage and increases for C#. For example, in one recent poll of developer language preferences for future projects, C# outnumbers VB by 3 to 1. Plus the survey was conducted on a VB focused site, so the figures are probably being
quite kind to poor old VB!