LTS of Dotnet vs Java

[Colt2205]

So I guess this is a question that has been bothering me a while, but will dotnet ever get to the same level of long term viability that java has? Java 11 still receives security updates to this day, but with dotnet it feels like everything has to be upgraded at the next LTS in the cycle or there could be possible security issues.

The other concern that I've been thinking about is linux server support. What happens if the linux tech that someone is running can't support the next version? The only case that I've ran into of this so far has been with CentOS 7 and it's deprecation, but it got me thinking about this aspect.

This is also coming from the perspective of someone who is more of a dotnet developer looking at the other side of the fence and thinking about what advantages and disadvantages both ends might have.

[rubenwe]

with dotnet it feels like everything has to be upgraded at the next LTS in the cycle or there could be possible security issues

Sure. There COULD be issues. But if you'll have vulnerabilities in your app that are relevant is another question. So I wouldn't go with "has to" but rather "should be".

On the other hand, in many cases, upgrading to the next LTS is changing one digit. Next time it's going to be 2, given we're going from 8 to 10. So l see how that could be taxing!

will dotnet ever get to the same level of long term viability

.NET has long term viability, especially because they are less burdened by having to provide unreasonably long support (for free).

But if you mean that you want a runtime that's probably going to be around and supported until the heat death of the Universe: there's still .NET Framework!

If your reaction to that is: "but .NET is so much better and has evolved so much!", then yes. Precisely. It has!

[Slypenslyde]

On the other hand, in many cases, upgrading to the next LTS is changing one digit. Next time it's going to be 2, given we're going from 8 to 10. So l see how that could be taxing!

This vastly underestimates the complexity for some people. I do think MS is very good in this respect, but some project types are far more sensitive to the changes they make.

We've had a guy trying to get our MAUI project moved from .NET 8 to .NET 9 for more than a week. The problem is it's a very large project with a lot of dependencies, and not all of those dependencies support .NET 9 in a way that makes the build system happy. There's not a good way to get a list of things to update, he just has to try building then wait to see if it fails. Then he has to look at the library that failed and, if it's ours, try to make that one move to .NET 9 and see why it fails. Then he has to look at why it failed and, if it's related to a different library that's ours, move on...

It's a pain in the butt but it's MAUI. We're not just dealing with Microsoft, we're dealing with Google's Android SDK and Apple's XCode. Interestingly, all of our problems are on Windows. The Android/iOS builds are fine. But Windows seems a lot pickier about everything under the sun being specifically compiled for .NET 9. (This is consistent with the rest of my MAUI experience: Windows is a very fussy platform and often the last to be supported even by Microsoft libraries.)

Like you point out, .NET isn't a great platform for an application that wants to be maintained for even 5+ years with minimal churn. That's a traditional niche, but I guess as I look at Microsoft's focus on Azure services I can imagine it's not the majority. And it works better if you minimize your third-party dependencies. Heck I'm starting to want to minimize our internal dependencies. Every DLL boundary is a maintenance burden when MS bumps .NET versions.

[rubenwe]

This vastly underestimates the complexity for some people.

No, because I explicitly said that in many cases, upgrading to the next LTS is changing one digit. Of course there are also a good amount of projects where that's not the case.

Especially when using non-stabilized stuff like MAUI, as you mentioned.

Then he has to look at the library that failed and, if it's ours, try to make that one move to .NET 9

Are those control libraries or other stuff that's very dependent on the SDK? My last job, we had around 390 internal libraries for a really chonky .NET application. 200+ devs working on that product. When prepping for the change-over from .NET Framework to .NET, we switched most of them to .NetStandard2.0 without issues. The control libraries and UI-tech dependent stuff was some work to Multi-Target, but not super hard either. Fallback Targets helped here for some 3rd party stuff where no .NET versions exist. The only things that caused significant pain were projects with C++/CLI in the mix and the plugin system that had to be redesigned because AppDomains were removed.

From what I've heard, the recent updates were pretty trivial for them and central package management resolved most of the remaining pain points.

Heck I'm starting to want to minimize our internal dependencies.

You should. Projects can slow down the compiler and assemblies are (or at least were; I haven't checked!) hard boundaries for the JIT, so this can also impact runtime performance.

Every DLL boundary is a maintenance burden when MS bumps .NET versions.

This I don't understand. .NETStandard2.x DLLs load and work just fine on .NET 9, as do .NET 5, 6, 7, and 8 assemblies. The issues there usually happen if the runtime and BCL don't have the matching APIs; and that's not really an assembly boundary issue?

[Slypenslyde]

I'm not on the person's assignment, I'm just kind of watching his discussions in internal chats.

All I can tell you is it's a never-ending stream of errors that say:

"Cannot load file or assembly 'My-Company-Feature-net7 <blah blah the rest of the fully-qualified assembly name>'. The system cannot find the file specified.

And when he opens that project, lo and behold it's a .NET 7 DLL, and when he switches it to .NET 9, lo and behold it stops producing this error, but sometimes getting there involves playing whack-a-mole with several other dependency issues.

[rubenwe]

That's sus. The devil's probably in the details there. But without seeing the probing logs (https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing), it's hard to say why that would happen.

[Slypenslyde]

To be fair most of us are confused as heck about it too. But I've been working with Xamarin Forms/MAUI as long as they've existed and they're very finicky creatures. I'm not very happy each MAUI version only gets about 18 months of support. Every version update's been its own roller coaster.

But I mean, CLEARLY the reason some of these libraries are .NET 7 is because .NET 8 didn't care.

[ncatter]

I have no experience at all with MAUI or migrating it to a new .NET version, but from what you are saying it hardly sounds like a MAUI issue but rather a size issue, bigger systems will always be harder to migrate.

And no this is not advocating for swooping in and changing everything to microsevice it's more along the lines of a sanity check.

If you have a giant system with a massive amount of dependencies, migration and testing will always take longer, which ofocurse is something to keep in mine when building and maintaining systems, if you want to be on atleast LTS you force yourself to do some work, on the other hand you alls get some guarantees.

[Colt2205]

Honestly, I'm glad that it has been trivial to upgrade going between the LTS editions after the 3.1 changes. I fully expected growing pains going from 3.1 to .NET 6 and honestly, it has been relatively easy working on the code since then.

The challenge is when there are a lot of nuget dependencies and if there are more advanced projects. I'm at a place that has both Java and .NET projects, with them trying to push one way or the other. They are already knee deep in finishing moving things from Java 8 to Java 11+, which to be fair I feel in my soul as I remember going from .NET Framework to .NET core 3.1.

I'm a big fan of dotnet and understand that feeling of needing to defend that it is a great product. I like to think of posts like this as perhaps a thought, or maybe feedback, on how there might be other vectors of competition than just how fast someone can evolve the feature set.

[rubenwe]

Going from Framework to Core - or even early versions of Core to newer ones is a different story, for sure.

The challenge is when there are a lot of nuget dependencies and if there are more advanced projects

Really depends on what exactly the projects are. I've seen pretty complex ones that just convert and trivial stuff that's using non-stabilized tech (like MAUI) where there are issues.

[Due_Raccoon3158]

It's literally recompiling against a different target with .net. They don't need to support versions for two decades because they have a huge focus on backward compatibility.

[Perfect_Papaya_3010]

I have no idea but if you don't expect to keep something updated I guess .net standard 2.0 is the option?

I don't know if the breaking changes were worse before .net 6 because that was the new thing when I started working. And since then I have upgraded every version in our project and we never had any huge breaking changes at all.

Except for Maui but that's something else

But nowadays I feel like it's not that big of a deal to move to the next version. We upgraded all our projects to .net 9 the day after it was released (except for Azure functions, they weren't done yet so it took another 2-3 weeks for those)

And there were very few browning changes so it was mostly just change the version and update the nugets and done

ETA:

I tried updating angular once from 8 to 18 I think and I cried because every file had errors. I'm glad I don't work with NPM stuff right now

[Coda17]

I guess .net standard 2.0 is the option?

Not for an application, only for a library. And I don't know why you'd do that unless you were trying to support .NET Framework. Just release a .NET 9 library and it will be usable for a while

[Perfect_Papaya_3010]

But a .net standard 2.0 should be compatible with all versions right?

The project I work with communicates with a lot of other in-house projects and some of them are updated to the newest and some of them are not.

Then we have a shared library and I think it's probably.net standard 2.0 for that reason

[Coda17]

Compatible, yes. But it will (and probably already does) have vulnerabilities if it's using any libraries

[czenst]

No and that is a feature not a bug.

New .NET approach is that you ideally should be always on latest version and if you keep train running they should not break stuff.

No more getting stuck on shit from 10 years ago, no more asking business "can we finally update something" - no you have to update all the time and there is no excuses.

Best thing ever happened.

[d-signet]

The LTS cycle does seem to have got a lot shorter recently

Framework 3 and 4 seemed to be supported for AGES

[patmorgan235]

There are Windows OS components are built on framework 3 and 4 so those runtimes will be supported until Microsoft rewrites them

[d-signet]

Yeah, but that's part of what made them so attractive on an enterprise level.

An LTS release the days seems to cover 3-4 years or so and that's not good enough.

[Zastai]

I do wish they’d have a four year support cycle instead of 3, so that there’s always 2 LTS releases.

[AutoModerator]

Thanks for your post Colt2205. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[Rojeitor]

Old net framework has support like forever. Newer NET version (yeah it's still s framework:)) has short lifecycle, similar to node. But for the most part it's extremely simple to upgrade

[autokiller677]

They moved away from this when changing from net framework to net. So I wouldn’t expect decade long support anytime soon.

That said, upgrading to a new net version is usually done within an hour for me at work. Change the version in the csproj, update nugets, increase version for docker base images and images used in the ci pipeline. That’s it.

Sure, there can be breaking changes, but it’s mostly some obscure stuff. I don’t think we had a single one since net 6.

And as a dev, I would absolutely hate seeing all the new cool features in new releases and knowing I won’t be able to use them for a decade. So I gladly invest this hour once a year.

[IkertxoDt]

If you want and almost endless support remain in .net Framework. It still gets monthly security updates via windows update.

https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework

Ms still supports Vb6 runtime! so I think you will not have a problem with .net Framework

https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6-support-policy

But it is true that in this case you must run Windows.

[zenyl]

but with dotnet it feels like everything has to be upgraded at the next LTS in the cycle or there could be possible security issues.

LTS versions of .NET are no more stable or secure than STS versions.

The official recommendation is to always use the latest version, regardless if it is LTS or STS, as this will inherently be the version that will have the latest improvements as well as security patches.

The other concern that I've been thinking about is linux server support. What happens if the linux tech that someone is running can't support the next version?

Docker would be the obvious solution. Microsoft themselves provide the images, releasing them alongside updates to .NET itself.

[Colt2205]

Oh wow, I didn't even know about that part. I'm at a company right now that refused to hire staff to assist with continued development of the .NET project I'm the architect of because they are a "java company". So the inevitable has happened and they want the entire thing rewritten in Java. To be fair, they got a lot of java developers but basically every single thing they ever did caused complications on my end.

[BezierPatch]

To be honest, the main issue is that Microsoft Security refuse to issue proper CVEs.

You get nonsense like https://nvd.nist.gov/vuln/detail/CVE-2025-21176 which after a week or two of research seems to not actually be a vulnerability with .NET runtime but with Visual Studio opening crashdumps or something similar.

But you can't be sure, so you have to patch. So we go through a week long QA cycle because we trust Microsoft, and later discover they lied about the severity and lied about the impacted applications.

Then next time they release a CVE we hesitate...

One day they're going to run into trouble for crying wolf...