Daniel Smith

Daniel Smith Daniel Smith

Niner since 2009


  • A Preview of C# 8 with Mads Torgersen

    What was it Anders used to say about starting off each new language feature with a negative score before it could be added?  A few of the recent additions in 7/7.1 feel a little bit corner-casey to me, however, I'm confident all four of the above will be really strong additions to C# 8.

    Extension everything has been a long time coming, and is probably one of the most requested features since extension methods were introduced, but it looks like it'll be worth the wait to get it done right.  I really like the new dedicated syntax for this, and can see a lot of thought has gone into future extensibility of it as well.

    I'm also really impressed with the approach to solving the nullable reference problem.  It's a tough nut to crack taking into account legacy code, but it definitely feels like the right way to go.

  • Bug Killer – A Channel 9 Halloween special

    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!

  • PDC09: Application Deployment with Microsoft SQL Server 2008 R2

    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 Sad

  • Rico Mariani: Inside Visual Studio Beta 2 - Performance and Reliability

    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 Smiley


    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?

  • Hanselminut​es on 9 - Why Aren't There More WinForms Talks with Rocky Lhotka

    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.


  • Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

    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!



  • Expert to Expert: Erik Meijer and Anders Hejlsberg - The Future of C#

    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;


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


    • 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.


    • Would make the original extension method syntax redundant Smiley
  • 10-4 Episode 10: Making Web Deployment Easier

    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 Sad