What I Learned About .NET Framework in 2021

Loupe is a forward-looking logging system. We recently updated Loupe to have client-side logging and .NET 5 support, for instance, to help our users making cutting-edge browser-based applications on the newest .NET.

But that’s not the reality for many developers.

Most developers don’t have the luxury to work with .NET 5 yet. I have spent lots of time researching and writing about .NET 5, but how many of our users will get to run their applications on it? I don’t have an exact answer, but the question itself made me realize that it could be valuable to spend some more time looking at other versions of .NET.

That’s why I decided to build a brand new WPF application with .NET Framework 4.7.2. Let’s discuss what I have learned.

Building The Application

The application itself is, to be frank, very silly. Let me introduce: the Gibraltar Dog Viewer!

Screen shot of homepage for WPF application gibraltar dog viewer

I decided to make a dog themed application precisely because:

  1. I like dogs

  2. It could be a fun theme for a demo application

  3. This theme is probably the only way I can get my Mother to install a WPF application on her laptop (for my entire career, I have relied on my Mother for user testing).

This application is very basic. But even so, it was still a handy way for me to learn more about making desktop applications in 2021. Here’s what I took away from the process.

Claims of .NET Framework’s death are overreactions

Nothing apocalyptic has happened with .NET Framework in 2021, even if Microsoft isn’t actively developing it. Visual Studio didn’t shame me when I chose to create a WPF project with .NET Framework 4.7.2 instead of .NET 5.

It was effortless to find tutorial information for WPF on .NET Framework as well. The information is not going anywhere. While it may be hard to get new developers enthusiastic about working with .NET Framework in the future, it shouldn’t be that hard to train them up for it. As long as Microsoft doesn’t demolish their documentation on .NET Framework (which, as of right now, would make no sense), this content should remain on SERPs for the following years.

So, if it looks like your organization will be using .NET Framework for a while, don’t sweat it. It might even be an okay framework for internal applications where your primary concern is low maintenance. The newest .NET is faster for sure, but it will require upgrading once every three years at a minimum. .NET Framework 4.8 is primed to not require any significant changes for… maybe decades? However long it is tied to the operating system. Comparing its support period to those of the newer and future .NETs makes .NET Framework look appealing.

Graph showing the support periods for .NET framework, .NET Core, .NET 5 and the next 5 years .NET releases. The .NET framework bar spans the entire graph while the newer versions get 3 years max.

Ultimately, I see .NET Framework as safe to stay on for a while and maybe an okay option for internal applications that won’t need frequent feature updates and require easy maintenance. No .NET Framework developer needs to hit the panic button quite yet.

Centralized logging is huge for desktop application development

My previous job was a web developer position for a small company. I would have loved a tool like Loupe for that position, as logging into the webserver to view my site’s logs was annoying. But it was possible to do from pretty much any computer I used, and I only needed to remember one set of credentials.

With even the most basic desktop application, though, my experience was different. I started out building the application without connecting it to my instance of Loupe Server. At first, it was no problem. I followed a tutorial pretty closely, the application only had one user, and existed on one computer. But I started to play around with the application outside the tutorials’ bounds, and my Mother wanted to see the “nice dog app” I was making. So, I saved what I was doing and eventually got her an executable.

And it crashed immediately on startup.

Screen shot of the application running into an error, due to a mispelled reference

Luckily for me, I knew this error. I added it on purpose for a Loupe tutorial and forgot to fix it before sending over the application. But it made me wonder what I would have done if I didn’t know the error and it only existed on her machine? Would I need screenshots of the application to diagnose the issue? Would I be remoting onto my Mother’s computer to grab some local log data? Or maybe if my Mother weren’t so nice, I just would have never known about the error until I started working on the application later. All these options feel a bit too clumsy for me when I have gotten used to the convenience of accessing logs wherever I want from wherever they appear.

Transitioning to .NET 5 will be tricky for some WPF developers

I decided to see if I could migrate the application to .NET 5. WPF is part of .NET 5, so I should be able to do it without much issue.

I started by running the .NET Portability Analyzer to see what it predicted for my application. According to the HTML report, my application should transition to .NET 5 without issue.

Screen shot of HTML report showing 100% score for .NET 5 compatability

As of right now, Loupe only supports .NET 5 for ASP.NET Core and Entity Framework. WPF and WinForms are on the way. So that explains why my application didn’t work on .NET 5. I would have had some warning if I decided to use the excel report with the .NET Portability Analyzer, as that report includes a category for “Unresolved Assemblies,” where I would have found the Gibraltar Agent.

Screen shot of excel report showing the unresolved assembly tab

Many packages that WPF developers rely on right now don’t have .NET 5 versions. Some will get a .NET 5 update eventually. Some will not. But if you are considering migrating an application to .NET 5, be sure to double-check your dependencies. You will likely need to figure out how to update those or delay your upgrade until everything has a .NET 5 update.

So, is .NET Framework in 2021 any good?

My answer is that it seems fine for developers who want to delay upgrading to the new .NET for a while or for applications with no real reason to need the performance bumps and new features available in .NET 5. Desktop applications are still part of Microsoft’s future, and .NET Framework was the Windows desktop development platform for a long time. I just think that if you do go down this road, find some form of centralized logging to keep things easy!

Are you releasing dog viewer?

Maybe? I’ve been using it for some Loupe training and making a new series of tutorials. I have liked it because it is a super basic app that is easy to break/fix intentionally. But it is far from my best work. If I released it, it would be primarily for training Loupe users in a controlled environment.

You can catch a glimpse of it in the new series of Loupe tutorials I have uploaded to our Youtube channel. You can follow along these videos for yourself using the Loupe trial, as I used the trial myself! You can give it a spin with the link below.

Try Out Loupe Server

Rock solid centralized logging

Unlimited applications, unlimited errors, scalable from solo startup to enterprise.