TWIL vol.3 (.NET Framework limitations, VS2022 and legacy apps, and the default keyword)

New year, new discoveries. Here a few things I learned this week...

Limitations of the .NET Framework

I've spent quite a bit of time over the last 18 months covering the (somewhat) newer features in C# that might help some of us survive WinForms development, but that's only gone so far because the .NET Framework only goes so far!

While the .NET Framework is supported for the foreseeable future, per this and this the best we'll ever get is whatever's in C# 7.0 - don't expect anything newer. Luckily there's an upgrade assistant that can help migrate legacy apps to .NET 6, but MS admits near the end that "Most certainly you'll have more work to do in finishing the upgrade.". There's no way a huge legacy app is going to convert over cleanly.

What I'd like to do this year is find something (or several things) to use the upgrade assistant on, get familiar with it, maybe write a thing or two if it seems helpful, and then learn more about everything from C# 8.0 onwards. At the very least, I'd like to know more about pattern matching additions, records, and the strange new top-level statements that look so different from anything I've written in C# up til now.

VS 2022 doesn't support old WinForms apps

Speaking of the future of legacy WinForms, I installed VS 2022 awhile back, but only recently tried opening our flagship (legacy) app in it. After all, it works just fine in VS 2019. Unfortunately, VS 2022 won't show any of the Forms in the designer view.

The reason why is explained by a couple Microsoft developers in this thread. I wrote more about it in a post of my own, along with a summary of what they shared and a simple example that recreates the problem.

Why doesn’t VS 2022 show my WinForms UI at design time?

I opened a legacy WinForms app in VS2022, just to be greeted by white screens of brokenness when viewing any of the Forms. Here’s why.

G.Winney 🖱Grant Winney

Should I use default or null... or both?

It's funny how easy it is to get thrown for a loop when someone else on the team does something a different way? It can be the tiniest thing, like using (or not using) curly braces around an "if" statement. We're creatures of habit. Oh sure, sometimes one way or the other is clearly better, but most of the time it's like loading the dishwasher. Everyone has an opinion, but in the end who cares as long as the dishes get clean?

Someone I work with prefers to use default instead of null to check for a missing value. It threw me off at first, because I'm just so conditioned to using null whenever I'm comparing something that might have no value. But then how many times have I called FirstOrDefault() over the years, literally telling the app to either hand me the first item or the default value, and then compared that to null? Wouldn't it make more sense like this?

var food = new List<Food>();
var soup = food.FirstOrDefault(x => x.Type == "Soup");

if (soup == default)
{
    // no soup for you
}

Anyway, the default literal isn't something I used before, but I read about it and it's on my radar now. In truth, you can't just replace null with default, except in a couple cases like reference types and nullable<T> since the default type for those is null. For everything else, there's a specific default type, and I can't decide which of these I'd prefer (for example)...

int grossIncome = GetGrossIncome();  // returns 0 if no income

if (grossIncome == 0)
{
    // you earned nothing!
}

if (grossIncome == default)
{
    // you earned nothing!
}

Which one do you think is easier to read and reason through?