On Dangers and Joys of Modernizing your .NET Application
With all the buzz around social media lately, where people jumping on the next Twitter Killer every week or so, I thought it would be appropriate to shake the dust off my old trusty blog. It may be not the money-maker as hot account at huge social site, but no one is going to shadow ban my RSS feed. I hope.
Sadly, I neglected it for a while and it stuck at ancient .NET 3.1. I needed to bring it to this century somehow. I do have some experience upgrading to newer, latest and greatest version. That didn't feel me with confidence, but a man's gotta do what a man's gotta do. My approach was naive and childish, I guess:
- Pull old code from Github. I don't have 3.1 on my machine, so VS freaked out with all reds.
- Flip version number in the project files to 7.0.
- Upgrade all NuGet packages to the latest.
- Restore and rebuild.
That should not work under any circumstances, and it didn't. I got about dozen warnings and 2 (two!) errors. I fixed them expecting to get more and more, but it strangely went green and loaded web application just fine. If it's not a miracle, then definitely a success story that I want to share.
Few things, I think, contributed to it:
- At the time of this writing, .NET 7 is a mature platform and all third-party code libraries had enough time to adjust. Pretty sure if I jumped on update when it was new hotness, that wouldn't go well.
- There is nothing fancy and "advanced" in the code, except maybe early server-side Blazor implementation - but it held surprisingly well. Simplicity pays off.
- There is advantage in using enterprise tech - tell what you want about Microsoft, but it will take care of old versions no matter how ugly and bloated new version becomes. Not necessarily a good thing, but in cases like mine here, it helps.
So if there some really old pet project you afraid to touch, it may be not as bad as you might think. Just give it a try.
