Daniel Smith

As with all great fiction, it's probably rooted in some elements of truth.  Laura and Tina certainly portrayed the irritating chattering bugs with great skill!

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.

-Dan

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!

http://geekswithblogs.net/iupdateable/archive/2009/04/02/msdn-poll-april-8th-2009-what-language-would-you-like.aspx

-Dan

Here's an example of how I'd implement extensions:

public extends DateTime
{
    // Extension property
    public DateTime Tomorrow
    {
        get { return this.AddDays(1); }
    }

    // Extension method
    public DateTime SetTime(int hour, int min, int sec)
    {
        return new DateTime(this.Year, this.Month, this.Day, hour, min, sec);
    }

    // Static extension method
    public static int DaysBetween(DateTime startDate, DateTime endDate)
    {
        return endDate.Subtract(startDate).Days;
    }
}

Notes

• The "this" keyword represents the instance of the object the extension method/property is attached to.

Benefits

• There is no need for a dummy "this" parameter on the extension methods as with the old syntax.
• Extensibility - it would be easy to see how other extensions could be added e.g. indexers, etc.
• Keeps all your extensions for a class together.
• Clean, concise, familiar syntax without any freaky context keyword tricks.
• Other than the enclosing "extends X" everything inside the braces is normal code.
• The same rules that classes use for the "this" keyword apply to the new "extends X" construct i.e. the "this" keyword can only be used in the non-static extension methods.

Downsides

• Would make the original extension method syntax redundant

Will these changes also be available for the App.config file in non web apps?

I like the new WFP based Visual Studio by the way, but hate the change from +/- to the dreaded Vista style arrows