❔ .NET Framework 4.8 Vs .Net Core for Longterm Support
So .NET Framework 4.8 has an indeinfite support while .NET 6 is going to go EOL in Nov, 2024 while .NET 8 will in Nov, 2026.
What is better to go with for long term support? Say I didn't want to update the program at all and everything necessary dependency wise will always be included and function as intended. Is there a reason to go for .NET 6 outside of Framework 4.8 if I am not going to use new features?
I know .NET Core has newer features and better support for the long term, but if I wasn't constantly upgrading the project to 6 -> 7 -> 8 -> 9 etc and just want the program to work on windows 10+ for say the next 30 years without any code updates, what would you think is a better option?
You can assume the program will function as an automated tester that sends and receives web requests only, based on specific results. Nothing else.
53 Replies
.NET 5+
.NET 5+ gives you Native AoT and self-contained builds, so you get to build your application without ANY dependencies on a pre-installed framework
your only dependency is the CPU architecture
and whatever OS-specific APIs you may rely on
Oh yea I made a mistake it was meant to be .NET 6,7,8,9
But that's great. So with a self contained build, and all future versions of windows, .NET 5+ will still run for the foreseeable future?
I mean, you could say the same thing about any version of .NET, really
including Framework
eventually .NET 4.8 will lose "support" and stop being included with Windows itself
but you'll always be able to install it
so long as you can get ahold of a copy
same for any of the .NET 5+ versions
This will probably never happen
a self-contained build really just streamline this process
At least in any reasonable time frame
the build literally just includes a copy of the whole framework within your deployed executable
Native AoT does kinda the same, but also includes a lot of optimizations to reduce the build size
either way, the builds will run on a compatible machine and OS, regardless of whether they're "supported" or not
imagine if your .NET 5 app magically stopped working after the EOL date
nightmare
yeah, that's not what EoL means
the most significant thing it means is that that version of .NET will stop receiving security updates
it also means, ostensibly, you can no longer go to Microsoft for "support"
Well the problem lies with Microsoft. A good example would be Windows 7/8 Won't have support for .NET 8, which if you think about it like that. Future OS's like Windows may have the same problem with later release versions. That's what I'm worried about really.
if you're running on 7 or 8, it's on you to test that your app works at this point
the reason Windows 7 doesn't "support" .NET 8 is mainly about what OS APIs it supports
not that .NET 8 can't install or run
well, there might not be a ready-made installer for it
and it's not like Windows 10+ are removing a bunch of OS APIs that Windows 7/8 had
not the core ones you're likely to use, anyway
your best bet for building something that's REALLY future-proof is to minimize the amount of reliance you have on the OS
stuff like reading/writing files is fine, those APIs aren't changing any time soon
but if you're building a GUI, well
Yea I think I'm thinking too far ahead lol. Maybe I'll think for the shorter term 10-15 years rather than extremely long term. Was just saying that what happened with windows 7/8 may eventually happen with 10 in the future. Cause a company is currently using outdated tech and I'm just trying to see what is the better option for decent long term support.
the salient point in my mind is that if you DO run into the need to update for compatibility, updating within tthe .NET 5+ stream is going to be WAY easier
the .NET team has been doing a pretty solid job about avoiding breaking changes
Yea sadly it gets a little tricky, I guess it's about time they get to the times and just update. Should be fine for now.
But yea, so far .net 6+ seems to be the better option and it will be on them to maintain it down the road. Should be good for a decade or two, maybe three probs
what're you building?
No doubt about that. I think .NET Core will be better down the line for them.
Essentially a program that automates tests based on harfware they make. Just automatically gets values under specific load, sends that to a db with a few web requests and repeats that endlessly, while making like 2-3 more requests as POST to other places. Kind of a core piece of their infrastructure and while I may be able to get them to update now, was just thinking about the future since it's a core piece.
have to stick with .NET though as that's what they've asked for.
I mean, like, a Desktop GUI?
Will mostly be console based, and then have a web ui. So it wont use winforms, wpf and any UI framework.
perfect
you're very very unlikely have those kinda things break from OS updates, I'd say
you're pretty much just using file I/O and socket I/O
and your UIs are all browser-based, so, pretty reliable for backwards compatibility
Yea pretty much lol and I think possibly a COM interface, but I think that'll be fine and supported easily
HTML/JS/CSS doesn't really DO breaking changes
Thanks for the help.
You reckon it is wiser to wait for .NET 8 before starting since it's coming out real soon? Or .NET 6 would be better as all the bugs and optimizations throughout the years through updates may make it "smoother"?
start sooner rather than later
like I said, upgrading .NET versions since 5 is all but seamless
Alright.
Hopefully
EDIT: Oh just checked, it is that easy damn
has been for me
yea seems fairly easy wow
it's stupid easy
the only thing to worry about is breaking changes
and they're VERY few and far between
like "this method you're calling in .NET 6 doesn't exist in .NET 8"
Breaking changes in .NET 7
Navigate to the breaking changes in .NET 7.
Yea probably minimal tbh. Don't see there being that many changes
That list is a little bit extensive but I think for the current application in mind it won't be that bad.
just the fact that a comprehensive list EXISTS is a huge help
you ought to make an effort to bump the NET version every year if you can
and not build it once and then try to update it 6 years from now
For sure it does help, rather than make you go in blind
Well, I will let them know. But I am contracted, so I won't be maintaining it. Unless they decide to renew 🙂
I am just trying to do my best
ah I see
if the concern is that they upgrade to Windows 12 and your shit no longer works, I wouldn't worry
A) that's highly unlikely, especially for a non-GUI app
B) if they're competent, they're already including maintenance efforts in their budgets for this acquisition
and if they're not competent, that's not your problem
Well, I think they've learnt from that mistake already. They were forced to upgrade to win10 due to security concerns on 7. Their current application just quite runs and so they are on "red alert" for the future. Hence why I'm there. But yea, I tend to think a little bit too far ahead. I think they'll be alright with win 10-12 support and perhaps 13/14 too at the least.
but Windows 10 is the "final windows"
I think they're competent enough tbh
didn't you hear?
You had no idea when I was relieved to hear that back then. I got a huge disappointment when I heard about win 11 and even worse when I heard about the rumour for win12 coming out (apparently) in late 2024 due to win11 being hated on and doing terrible compared to 10.
yeah well, instead of counting Windows versions, we had to count build numbers to track breaking changes and new features
I'd definitely have been happy if Windows 10 was the last time they were like "let's rebuild all the UI stuff, cause reasons"
I'd accept the versioning being more tedious in exchange for that
but no
Yea I think if windows 10 was truly the last, this would still be the case. But I do think it would be a little bit more manageable than the version bumps
nah, it'd definitely be slightly less manageable
we'd just be shifting to tracking lower numbers in the hierarchy, like he said
or, it'd be like VS
they CALL 2019 and 2022 different versions
Yea the UI changes are horrid indeed. To make it worse, they "force" you to upgrade in a sense. Got a big shock when I got a wifi 6e card and realized you need windows 11 to use 6e... Microsoft tend to pull the shady cards like that refusing to include the "newer" tech in an "old" version fo windows
but the actual version number behind the scenes is totally different
Not sure about that but tbh, I consider them 2 "different" versions just because of the UI changes
I mean, like....
VS 2022 (currently) is actually version 17.5.3
(I'm a bit out of date, actually, it seems)
VS 2019 was version 16.11.29
VS 2017 was version 15.9.54
hmm, I could swear there was a point where the behind-the-scenes version was the same major version number for two different VS's
maybe I'm just mis-remembering
but still, the point is that they have separate versioning numbers from the "What you see" version
that's what Windows 10 would likely have become
Probably was but microsoft could've fixed the versioning later down the road? Unsure. Don't really keep up with the VS times. Been using vs2017 till recently with .net core forcing you to use the newer versions
I mean isn't it similar? Both use 22H2 atm for win10 and 11 in the titles
yeah, so we got the same mildly annoying end result, without the proposed benefits
for windows app devs, we were looking specifically at "build" numbers in this table https://en.wikipedia.org/wiki/Windows_10_version_history which is different from the version or codename, and you can crosscheck that with https://learn.microsoft.com/en-us/windows/uwp/whats-new/windows-10-build-19041 (see sidebar)
Oh makes sense I see
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.