Herodevs user here. We use their vue2 support, because migrating 20 services with a team of 3 people is not an option. Their support has been a good experience so far.
My biggest issue with this whole release policy is defining 3 years as long term. Three years is at best mid term. We need releases that are officially supported 5+ years so that we don't need to constantly go back and touch working projects.
I don't get this argument because if you're not touching working projects then you're also *probably* not upgrading dotnet runtime minor versions on the machine where your project is running. So why does it matter if you're getting 3 or 5 years of support if you're most likely not utilising the benefits of the support. Unless I'm missing something
Alone due dependency updates, which often also are updated to fix security vulnerabilities, you need to touch working projects to fix them. In this cycle to also update the .NET version wouldn't be the biggest additional work.
My company never upgrades to the 18 month support versions. It takes us about a year to upgrade to the long-term support versions (6, 8, 10) and we just finished upgrading all of our .NET 6 solutions to .NET 8 last month. If we stopped developing new solutions and just dedicated a month or so to .NET upgrades, I'm sure we could get all of our services upgraded faster, but if we upgraded for every release, it would just be a neverending revolving door of upgrades, and it just isn't worth it at that point.
New microservices as easy to update piecemeal and we've already started our Net 8 to Net 9 migration for these services. Our major problem is that the monolith is tightly coupled and needs to be upgraded in one big hit. we reckon it'll take our 7 dev about 3 weeks to do this. However for us there is a code freeze at year end so we'll take the opportunity to do the upgrade in December. Is it a coincidence that the LTS and STS releases are in November and not January?
I'm jealous. I am in an erp ecosystem that has a major release every 6 months. Without a doubt there are there are always some breaking changes. Even the minor versions will sometimes randomly break things but aren't technically breaking changes. We spend more time staying compatible than ever before. We're at the point where we are thinking of hiring a Dev team responsible only for staying compatible.
Wow, sounds like a big failure if you need many men working for weeks just to change a version number from 8 to 9 on your csproj files and maybe update some NuGets with a press of a button in Visual Studio
Maybe your team can benefit of some handy tools like Renovate (or Dependabot) and Central Package Management (CPM) and Directory.Build.props. This could be really useful to speedup and make safe this kind of massive migrations.
From my experience, it's either draconian compliance or lack of automated testing that slows the adoption of new versions of dependencies. The better coverage and more autonomy (and accountability) you have as a team, the easier it is to move forward quickly.
A responsible of coverage and update dependencies here! Yeah, I totally agree with you. I introduced build validation policy (unit test have to pass always everywhere), diff coverage policy on Pull Requests and Renovate scheduled to update all dependencies. The life is just easier.
@@JonasThente-ji5xxA lot of companies have dev resources prioritised towards customer requests and bug fixes as opposed to updating the framework constantly. It’s a matter of time, resources and priorities, vs the benefits of upgrading and the risks of not.
@@discbrakefan Yeah, I understand that. But when a new .NET version has been released, and I'm working on something else in a service/application, I simply just update .NET and its NuGet packages at the same time. It takes like a few minutes. I don't know why you would want to run outdated NuGet packages anyways.
Considering that .Net 9 is still not close to feature parity with .Net Framework, there are a lot of projects that want to use something more recent but are simply not able. We have a number of WinForms stuff where I work that are eager to update but not able to because no upgrade path exists.
For real. My last job the vast majority of the code was still running on Fw 3.5 - in 2023. A couple projects were on Fw 2.0. I asked permission to upgrade one _peripheral_ project to .NET 8 (LTS), they insisted on updating it to .NET 7 (out of support for several months) instead. Bosses don't understand the meaning of LTS releases.
You will laugh but in outsourcing the client's approval is the biggest factor in upgrading or not. You can give them the biggest list of advantages if they say no, it's a no. They will upgrade when they see the monetary impact of not doing it otherwise delay until needed.
Which is not a bad strategy most of the time... Devs need to touch grass. "Performance improvements" - even huge - in most LoB apps (most of the .NET world) don't make a difference at all.
people saying LTS doesn't always mean that their company doesn't want to move to the latest version... but often it is a limitation of cloud providers like AWS. For example, you can't deploy .NET 9 Lambda to AWS, so AWS is dictating what version we should use :(
Its never just a simple update. Not because of the compatibility but because nugets are deprecated due to security and you may want to use a new feature and that changes code
It would be much better if Microsoft upgraded .NET, C# etc. when they have a decent pool of worthy changes that make sense to upgrade to, instead of producing "something" every 12 months just to produce something. I don't have a problem in waiting 17 months for something new if it's worth it. I don't think even the shareholders or analysts think that deploying something every year will raise/lower the stock price.
I would prefer them to have focus on runtime and languages in odd years, libraries in even years. There is lots of stuff missing that is simply there in Java.
It would be nice if LTS had 4 years support rather than 3, so that when time comes we could update to the latest version instead of an LTS that only has 1 year left. I.E. 6 to 10, 8 to 12.
I think that if Microsoft move to Forever support none will move to newer versions, leading to lack of engagement. Having all dotnet versions as LTS would be perfect
I find value in both approaches. For internal applications that doesn't need new features or constant updating the Never-ending support fits perfectly. For Cloud based SaaS applications though performance benefits mean cost reductions which is the primary reason to upgrade.
Upgrading once a year just doesn't work for smaller teams. Sticking to an LTS rhythm is far more viable overall, esp when libraries you depend on might not upgrade as readily and cause issues.
The obsession that companies have with releasing a new version every single year is insane. Not every single product or service needs a new iteration each year.
Our company intended to upgrade from 6 to 8 in January, but that plan got kicked down the road due to other requirements needing the developer resources. Now we are at the stage where we must get off 6. We're just having the debate as to whether it should be 8 or 9. Everyone agrees that the effort to upgrade from 6 to 8 or from 6 to 9 about the same, and that 9 offers some significant performance benefits, especially around memory. So what's the issue? Given our track record of kicking upgrades down the road, if we went to 8 then we'd have 12 months to get off 8 when 10 drops, but if we were on 9 we'd only have 6 months. We've just agreed to go for 9 with the acknowledgement that the next upgrade window will be only 6 months. (People still have memories of the upgrade from 3 to 6 where we enforced the StyleCop rules across the board - hopefully 6 to 9 will be a lot less painful).
Delaying and then making big version leaps can be terrifying (and sometimes paralysing), due to potential breaking changes. This is possibly a good opportunity for you to push for more frequent and smaller version leaps in the future.
I didn't update our prod containers to net7 because 'not LTS', but all during that period we stayed on net6 we had to be wary of packages being updated and avoid any net7 specific updates. Broadly it's far easier to maintain packages on the 'latest' version of dotnet, even if that is an STS version. I don't think the STS/LTS distinction is too concerning personally. We started moving containers to net9 a day or two after release, and we'll try and maintain containers yearly regardless. I appreciate not all companies will be in a similar position with the freedom to move this fast though.
When looking at the poll responses, I think the .NET (core) community is staying updated quite well. With 18% still on .NET framework, the numbers for .NET core (70% on .NET 8, 7% on .NET 9) are quite impressive. That leaves only 5% on "other".
Java is up to 23, but it's not unusual to see projects stuck on java ~8 still. We have the same LTS issue; nobody wants to upgrade to something unsupported and tons of 'preview' features.
TBH, updating DOTNET version is A LOT easier than Java. Ive seen project that were stuck on specific MINOR versions of Jave, because of libraries emitting specific bytecode.
I think there is a good reason to update regularly, because the differences between versions are smaller and both testing and fixing issues are far more easy. I have landed several times in situations where the management thought upgrades would be a waste of money, but then the software became very unstable and we were forced to do a big upgrade project in a short time. This is very expensive.
I've voted .Net 8.0 in your poll. However, we do want to migrate to .Net 9.0 soon. Give it a few months and the survey will most likely have a very different result.
Believe him. We had a company developer meeting two or three years ago and managers and higher ups were in full agreement how much they hate .NET 9. We are still using pre adobe Cold Fusion for our finance and banking apps.
@@troncek In smaller companies and projects it doesn't make sense either. It's very very rare to even need performance improvements so why bother. It's not like there are some huge security holes in older .net versions.
For me, it was the complete overhaul they did of Blazor in version 8. I'm not going to argue one way or another on whether it should have been done. The fact is that they did it and it's almost impossible to upgrade a Blazor server app. I've never had success with any of the upgrade methods/guides; I've had to rewrite each one from scratch.
In consulting, you only upgrade from one version to another when you get paid for that, I mean, you offer it or the client ask for that, but always by contract. And when starting a new project we always go for de latest LTS.
I actually disagree. I think you need to have the non-LTS versions so that new features can be tweaked/hardened with slight breaking API changes before they make it into an LTS release. Some issues you just don't find until thousands of people are using your code. Having a period of time where API's can be tweaked is a must. The whole point of LTS is that the code you are running has been running in production for an extended period of time with no issues. Our team uses the STS version for our apps, but we dont work on anything where peoples lives depend on our software. If I was making medical, banking, or govornment systems, I would be sticking with LTS. The bigger issue which I have right now is that more often than not, when I encounter a bug in .NET (or one of it's many libraries maintained by MS), even if the version I am on is still supported, I see bugs get pushed and pushed and pushed and never fixed in the supported version... It's always punted to the next major version (or multiple major versions)... What is the point of having an LTS release if you aren't going to fix the bugs people report in it?
My experience is a bit different. I found a bug in Ef core, reported it on Github, and they fixed it in 2 minor versions. It took them around one month from the report to the fix.
I think you misunderstand .NET STS. The bar to introduce a breaking change is not any different than LTS. STS is not some place to test stuff and tweak, it is just as stable as LTS.
We will be upgrading to .NET 9 in January/February. We have a pretty large code base with several million lines of code. I performed the upgrade from .NET 6 to .NET 8 in March and we have decided to upgrade to STS versions as well so we benefit from the improvements as well as to make the upgrade steps smaller. We do have some larger Blazor applications which we also migrated from Blazor Server to the new Web App model introduced with .NET 8 in the upgrade process. It really helps to have unit tests on core logic, I guess. 😅
Just to add to this: The only real pain we have had was the negligence that Microsoft has regarding C++/CLI when it comes to newly released versions of .NET. We use that feature pretty heavily as we also have some old MFC rich clients that we need to integrate properly with our newer .NET code to not rewrite features in C++ as well.
It is extremely hard to make a video clickable on a topic that generally sounds mundane but I think is very important, so the TH-cam algorithm is to blame here. I could have titled this video ".NET's Support Policy has a Problem" but it would be watched less. I'm 100% with you, but it's the game I have to play unfortunately.
Nick didn't answer the question "Why...". It's a matter of app distribution. What is the target audience of the application? If you have a website that is located in the cloud, then of course you don’t think about it and can grab the latest update. But if you distribute applications in the form of distributions, you are limited by which platforms your application will run on. And not every user is ready to install new versions of .NET and not every operating system is compatible with new versions. Hence, one of the reasons to use LTS is the maximum time for users to decide and prepare for updates. Other reasons were also written by other users earlier in the comments.
I'm not upgrading to the STS versions. Can you honestly say that the new features of .NET 9 are enough over 8 to pay for costs of upgrade instead of going from LTS to LTS? Even if it's an hour per solution?
My thoughts as a developer: Most important motivation to upgrade is to be within support from Microsoft to mitigate security vulnerabilities. If there is a security vulnerbility that won't be patched in an older version, the company is taking a risk. All other benefits of upgrading are less important to the business. Agree that LTS and STS is confusing to people in business outside the dev team. An upgrade has to be planned and that takes time away from the business getting features that they ask for. Aside: Release schedule is good for dotnet. A release each year helps to reduce the number of breaking changes to fix and provides a better short term way to obsolete language features (if needed).
Yep, agreed, though I suspect they don't because it increases their servicing obligations. Debian LTS is at least 5 years, but I think Microsoft want to avoid another 'tyranny of forever-supported' situation.
I have control when to update Dot Net versions. Started a new project on Dot Net 9. An older project was upgraded from Dot Net 5 to 8 only last month, only because I was adding new functionality to it. Still have application in Classic ASP, Dot Net Framework 4.x, Dot Net Core 3.1, 6, 7 and 8. Eventually all the projects will be upgraded to latest version of Dot Net when request come in for new features, otherwise they will just sit there happily running. Just for reference, these are all internal applications.
I recently moved all our code to .NET 8 from Framework 4.8. That was some work! To go from 8 to 9, I'm expecting, is to simply run the upgrade tool (I am an optimist :) ), so when things slow down I'll do that.
Generally speaking, we upgrade versions at or near release of the newest version because it offers some compelling new feature that either drastically simplifies our code (generic arithmetic in 7, for example) or offers us the potential for significant performance boosts (params spans in 9, and something in 8 that I can’t quite recall). But we have the benefit of being an indie developer, so recompiling our libraries genuinely does come down to updating the project file, adding support for the new features we’re targeting, and recompiling.
It is not always as easy as just upgrading the version in csproj and dockerfile - you also need to make sure that all libraries you depend on have done the upgrade too. And sometimes upgrading a library may require jumping to the next major version which may have breaking changes. It is not a showstopper, just one of the reasons to postpone the upgrade a bit. To the time of release of .net 9 we've just completed the upgrade to 8th; we can now plan the next upgrade some time next year.
I do not mind STS and LTS system. STS can be when a new feature is introduced and a distilled version comes into the LTS. But, 3 years is just too short for LTS. If you simply upgrade the version but do not refactor the codebase to apply the new features your codebase become harder and harder to read as the newer styles start to mix with each other and your codebase becomes less coherent. Hard to sell why we have to do an upgrade every 3 years. Go changes less, and people really start to think it is less hassle with the upgrades as it changes less. The Course of creating an interpreted OO language and then try to make it compiled and functional.
Personally, in the industries I am and have worked in, clients simply will not consider running on anything but the LTS version _unless_ there is a *major* bug or critical vulnerability found in the current LTS version that is fixed in the newer release (and even then only in rare circumstances as the security exception process is... onerous). This applies to basically every language, library, and framework, not just .NET, and is written into the contracts.
I used same approach for over a decade of software development: use LTS, migrate to LTS. Meaning migration between versions on every 18-24 month. Thats not only about .NET this approach I prefer to use as common standard. Such approach allows to find balance between new feature expansion (CapEx) and Maintenance (OpEx) budgets. Stakeholders of projects are more negotiable to spend time onto maintenance once they don't hear every couple month about of upgrade and also its allows to keep development team balanced as project never falls into un-upgradable legacy void-hole
I agree fully in that MS should drop STS and only offer an LTS releases for every major release they make, like you said they have the capability. That being said I also truly think that a platform like HeroDevs is not something good for the community. As developers, we should look to new versions to get access to benefits, allow new junior developers to not have to work on legacy code they way many of us have and in general look after the systems we build. If it's so hard to upgrade your system to a new version you have something fundamentally wrong in your company. It can be tight or unreasonable time budgets over and over again, a leadership who doesn't understand the development cycle or simply put an understaffed team. All of these things is something you should reflect upon as a company. I've found myself in this exact position. Now I do also think that MS has not traditionally made it easy to upgrade between versions (think framework days and early core version). Later versions are absolutely much easier to move between but I think something more closely to what Angular is doing with automatic migrations and a clear migration guide between versions would really help the community.
We don't really have policies for when to upgrade. We have apps ranging from Framework to .NET 8. When a new version releases and I'm currently building a .NET project, I adopt it immediately. Otherwise, it just stays on whatever was the newest .NET version when the project was finished. I rarely get the time to touch finished projects and I would need a supervisor's approval because they have to figure out how to bill it or if it's covered by a maintenance contract.
I am currently migrating a .NET 4.8 server app to .NET Core. I am glad that my company gave me the freedom of choice, so I took .NET 9 and it is working fine so far. Question for Nick: Do you have a Aspire course on your site?
Usually upgrading is an easy as changing an 8 for a 9 in the project file. But most developments are done by outsourcing and they do not know where are the project files.
To be honest we updated to .Net 8 like 6 months ago. We kind of got screwed when we updated to EFCore 8 by them changing query generation to convert something previously would generate a WHERE IN, to an OPENJSON. They (Microsoft) say the performance penalty for OPENJSON is not that bad. Our experience begs to differ. The only issue I foresee with us switching to .Net 9 right away is really just putting everything else on hold and hoping all our nuget packages still work after the change. We probably will do it eventually. But we may wait a few months first. Besides that, there will probably a few performance and security patches for .Net 9 anyway. Microsoft tends to have it's users be part of it's extended qa team. We will wait till things are a little more stable.
For us, when I upgraded to .net 9 our back-end didn't transfer as smooth as I expected and I had to rewrite some of the IQueryable linqs because for some reason the EF wasn't able to translate them same as it did in .net 8 and I didn't feel confident enough to greenlight it if it broke some queries already. As for MAUI, they broke layout for Android and I'm no longer able to set it and it's always no limit, so I wait until they fix their issues with .net 9 first
we had a similar problem upgrading from net 6 to net 8. I guess is the same problem, they updated the compatibility version for sql server, changing the queries generated, and if your database is configured in a lower compatibility version number the querys will not be recognized. you can change that with 2 lines of code tho, no need to change the IQueriable expresions
It's understandable not to upgrade to STS if you don't plan to upgrade your project. But experience shows that upgrading multiple versions at once is always a huge leap. It's often easier to make small steps. However,, sometimes you are blocked by a library that prevents you from upgrading. That can be a problem hrad to deal with, and having choosen an LTS version in that particular case may be worth it
As of today, .net 8 is supported until Nov 2026 while .net 9 is supported until May 2026. Why should someone upgrade an enterprise project to .Net 9? I agree with you that if Microsoft wants people to upgrade, they should extend the support and all versions should be LTS. At the same time, I also want to say that some of the features for cloud native apps are not immediately supported. For example when we moved from 6 to 8, we only had isolated model for Azure functions project. We had to do code changes, the hooks to azure events changed the way they operate etc. So it is not about .Net runtime alone. It is also about cloud support for the runtime.
Reason to upgrade, security. Those that use unsupported .Net versions are opening themselves up to being hacked. New vulnerabilities are being found every day. I'm all for using supported older versions, until the lifecycle ends and support from Microsoft ends. Then it's really time to update. Not doing so opens up your company and its employees to being hacked.
We cannot run out of support software. LTS support is beyond the next release's support date, so best for us to just update on LTS versions. NuGet Manager in Visual Studio tries to push staying on the latest, which is problematic with wanting to stay on LTS only versions. If all releases were LTS, then we would probably update to latest to minimize updating pain. We are still migrating 4.8 framework code to .net 8.
In my opinion having the sts version is important since the technology is a advancing very rapidly and you need your favourite language and framework to keep up . Imagine if we are forced to wait 3 years just to get the IChatClient that deals with any AI model in a very standard way in a world competing over maximising the use of Ai in thier apps. Another important advantage is the simplicity of migrating from lts to sts and then from sts to the next lts, if we didn't have the sts then I imagine the upgrade from one lts to another lts will take much more effort.
I think this question, about what people are running in production, has been asked too soon. There are still plenty of packages that are in pre-release mode pending final QA, and some of them depend on pre-release of Microsoft packages as well. I'd start the upgrade to .NET 9 in a heartbet for all our projects, but right now it's more of a hassle than its worth, so I am delaying that upgrade a few weeks to let the package ecosystem stabilize around .NET 9.
Yeah, I never upgrade until after the new year. I also don't usually release the upgrades until there is a business need to release them. If there is no business need, then there is no reason to risk potentially releasing an unnoticed breaking change.
100% agree with this. For agres I have seen people not upgrading primarily because of the support model. And for other valid reasons such being too frequently or being too much work, that is only true if you are not accustomed to. it's like CI/CD, instead of fear of merging (or in this case upgrading) you just do it more frequently until is a no brainer. The benefits almost always outweigh the costs. It doesn't have to be an all-in-one upgrade either. You can start bumping the .NET version and upgrading nuget packages, later you can use more C# syntax and also newer framework features.
I think bigger problem than LTS or STS is support in different hosting platforms. I don't believe that their own Azure is supporting all services with .NET 9 version already. For example Azure Function were not properly supporting .NET 7 for very long time and i think .NET 8 was released before they fixed those issues for .NET 7 and it's nothing worse than figure it out those issues when you already updated everything and you have to revert everything back.
@@nickchapsas Are you saying that 9th most valuable company justifies 1000 microservices? I do not think there is a single use case in the world where a company would want a system made even of 500 microservices.
@@nickchapsas I could not find any statistics about how many microservices an average project within any of the tech giants have. I do not think that how complicated a project is has to do with the growing number of microservices. The amount of work that needs to be done to support a system of even 50 microservices will increase the cost of the project significantly. In my opinion, when I see someone says EXTREMELY complicated, it really smells like chaos and lost control. Payment gateways can have many volatilities but if there is a separate microservice per payment type, per customer type, per region, per timezone or similar (if you can say what made the project grow to such a large number of microservices, please let me know), then there is probably something wrong with the design. I have not seen the designs of the projects of any tech giants. But again, what they are doing does not necessarily mean that they are doing it properly. Why would you want even 50 microservices in a project? What do they all do?
If every release were an LTS with 3 years of support, we'd always have a mix of the latest version (new or recently updated code) the version release 2.0-2.9 years ago (everything else). End of life is an incentive to update.
Too clickbait-kind title, .Net9 was just released. And I don't hate anything (except maybe such titles), but I tried to migrate my project, one show-stopper bug in EF Core, one in Blazor. So I will wait, quality goes first.
yeah I am also waiting mor EF Core libraries I use to catch up and release a .NET 9 compatible version. the only stopper for me currently is waiting for other dependencies to update if they have to
What was your EF bug? I found one to do with how the EF parses child queries. I.e in EF9 it doesn’t pre-parse them whereas in EF8 is did. Which was an issue all the way back in EF6, I.e pre .Net core.
Many companies also have code freezes close to release of new .NET versions - and are often racing to get other changes out before said freezes. It's possible some of this is accounted for by lack of ability - be interesting to compare in the new year
It should be company policy to upgrade to the latest versions as they come out… upgrades become harder and take longer the longer you wait… that’s a $$$ risk for a company… therefore, all companies should enforce adopting the latest version sooner rather than later to protect their bottom line.
@@steve-wright-uk Considering migrating is trivial at this point there's no point to compare STS to LTS now. It makes more sense to compare .NET 8/9 to 10.
As someone that only takes the LTS versions (and keeps up with them); I like the STS / LTS model as I'm only getting updates every other year; but there is in the wild, field tested mid-release version (STS) that came between; so while I take on growing pains every two years; it isn't a flat "oh this has been in development without people using it" two-years ... so generally like this current release / support model.
@@fusedqyou Maybe they didn't have time to implement it fully. I don't subscribe to the idea I hate a product because they didn't add a feature to it vs an existing feature that doesn't work right or gives me grief.
Our biggest project is sadly still on .NET Framework, everything else is on 7, going to 8 in a few months, just hasn't happened yet because too many other things having to get done
This is not this.... the problem is always money... -"I would like to highlight the need to upgrade our systems to ensure its future functionality, compatibility with surrounding environments, and long-term sustainability. The system is a vital component of our operations, supporting [specific function, e.g., resource booking, data collection, etc." -"But It works? Dont need that we will buy something on the shelf" silent -" that never happens..and it wont work" We stil have a descent amount of classic asp and some webforms.
We only upgrade to LTS releases. It can take over a year for us to upgrade versions because of how slow our process is, how few resources we have and how legacy our applications are. So for us, it really doesn’t matter, we wouldn’t upgrade every version no matter what MS does.
Still moving from 6 to 8 while also migrating Azure Functions from "In-Process" to "Isolated worker" model which adds a little more work than just changing 6 to 8 in csproj/fsproj Oh and there is regular work that has to be done on top of just "updating" stuff...
When .NET was 4 years old, new developers mocked me for sticking with Delphi. Now, the codebase I work with is still partly 32 years old ... and it just compiles. When I hear complaints about .NET, I’m glad the toughest migration I faced was switching from 32-bit pointers and ANSI strings to UTF-16 (internal format). In 25 years, that has been the biggest migration challenge. Of course, we still test new versions-because when you’re dealing with 9 million lines of code, chances are something will break.
I don't know why this wasn't discussed earlier and is being brought up now. The 3 years LTS looks reasonable when we consider the goals with the new .NET. Yes the core problem is that there's not enough resources put on the .NET team (many features delayed, short support span etc), but let's not mind that for now, ofc longer support the better. But people often don't upgrade only because of NuGet dependencies that are not updated yet. This then chains on. It's part of maintenance to check what is there to update, so there's a chance to check that there's .NET 9 and see what happens when you try to update to it. If it's too complicated, leave it on next LTS. But having up to date services is part of the job isn't it? The more you leave it be, the harder it becomes. STS currently I agree is pretty tight and it would be better if it was extended by at least half a year.
I am a Lead Programmer, I was looking at upgrading to .NET 9 last week. But hit massive roadblocks due to lack of backwards compatibility with .NET 8 NuGets. For example, we couldn't adopt EF .NET 9 because we need Pomelo which was at the time of attempting (not sure if it is at the time of writing) not compatible with EF 9.0.x. We have decided to revisit the upgrade after Christmas. Hopefully giving our NuGet Package developers enough time to upgrade to .NET 9 themselves.
Came across the Pomelo issue as well. Had to stay at EF Core 8, which works good for .NET 9, it doesn't really block anything else from upgrading. Breaking changes in it's core .NET 9 from 8 are not significant, unless you're using Blazor or something more fresh. Of course it gets worse with complexity.
going from framework 4.8 to .net 5 was the hardest move ever, so many missing features. .net 5 to .net 6 was painful. now with everything on .net 8 and will only be going to .net 9 when all the packages needed are there.
We have a LOT of dotnet applications from 6 to 8. we don't care about Lts or sts. I usually wait one month before migrating to new dotnet version and when there is new features or some security issues
making lts be 6 years instead of 3 will do for me (everything else can be left as is). at least you will be able to dig into a somewhat big project (2-3 years) and implement it while the lts lasts. it is really inconvenient to have people assigned for upgrading while the project is still not finished and is not in the support phase
isn't .Net pretty much backward compatible since the .Net core 5 version? 'Migrating' to a newer version basically means installing it. IIRC they did change default boostraping fille/class (IIRC Program) in the version 6 or 7, but it didn't/doesn't break anything, old way of doing things still works.
We went full blast on .net7 and the .net8 upgrade was quite painful for a few projects, and I wish we had just stayed on .net6 for those. Lesson learnt; wait for the next lts
the biggest problem in my company is not because LTS/STS model, but because of a mindset of "why should we migrate if it's still working? let's add some features instead of wasting time on migration". And any changes made by Microsoft will not fix this)
Nick, I purchased your maui courses on dome train and I made an issue entering my email information. I can't access the courses. I've been reaching out to support without any responses. Can you lend a hand :X
I think that a lot people are still on .Net 4.x because the upgrade path was / is non-existant and there was no support and no documentation to support it. So any products built on .Net 4x are likely still there. My main product is still there because of this. I desperately want to be on the latest .Net Core but I can't justify the time it will take to get there and the unknowns that will have to be overcome to get there. Microsoft's approach to the early .Net Core of it not being a full replacement screwed us big time. It would have been ok if at some point they said "Ok, now is the time to consider this "the next version" of .Net, everyone should upgrade and here is the support / documentation to do it", but that didn't happen as far as I can tell. MS just abandoned .Net 4x users.
I like the approach of getting new features every year. Waiting 2 years seems like a lifetime in the tech space. The tech will become irrelevant real quick as competitors snatch up the space with newer tech
I one hundred percent agree with you. MS should just drop the STS model and stick with LTS. We are definitly upgrading to .NET 9.0 due to massive performance improvements and due to end-of-support for .NET 8.
IMO I think their current cadence is fine. We will only run LTS (we are on 8). I don't have upgraditis & there isn't anything from version to version that i generally HAVE to have. Honestly if their were supporting LTS on every release it would probably push us to upgrade to something we really don't HAVE to have.
Personally: I still have a ton of old crap on framework projects (inherited a lot of legacy), which has priority to get to "core". Once that is done I'll think about also updating to non-lts versions. E: those projects probably will go directly to .net 9, because doesn't matter, but the stuff that's on 8 now will stay there for the foreseeable future (read: until 10 comes out probably)
Herodevs user here. We use their vue2 support, because migrating 20 services with a team of 3 people is not an option. Their support has been a good experience so far.
Meanwhile my corporation still using WebForms released in 2002
The real OG's
WebForms was ahead of its time
Run
It works fine, a lot of banks around the globe use it
@@randypenajimenez3893 Banks using it is not necessarily a good endorsement for the technology.
My biggest issue with this whole release policy is defining 3 years as long term. Three years is at best mid term. We need releases that are officially supported 5+ years so that we don't need to constantly go back and touch working projects.
It's trivial to update
I don't get this argument because if you're not touching working projects then you're also *probably* not upgrading dotnet runtime minor versions on the machine where your project is running. So why does it matter if you're getting 3 or 5 years of support if you're most likely not utilising the benefits of the support. Unless I'm missing something
Alone due dependency updates, which often also are updated to fix security vulnerabilities, you need to touch working projects to fix them. In this cycle to also update the .NET version wouldn't be the biggest additional work.
@@JonasThente-ji5xxthat depends... Recently updated a load of azure functions from .net 6 to .net 8 - not trivial...
@@JonasThente-ji5xxThat is a blanket statement. It may be trivial for some teams/companies/apps, not so trivial for others
My company never upgrades to the 18 month support versions. It takes us about a year to upgrade to the long-term support versions (6, 8, 10) and we just finished upgrading all of our .NET 6 solutions to .NET 8 last month. If we stopped developing new solutions and just dedicated a month or so to .NET upgrades, I'm sure we could get all of our services upgraded faster, but if we upgraded for every release, it would just be a neverending revolving door of upgrades, and it just isn't worth it at that point.
New microservices as easy to update piecemeal and we've already started our Net 8 to Net 9 migration for these services. Our major problem is that the monolith is tightly coupled and needs to be upgraded in one big hit. we reckon it'll take our 7 dev about 3 weeks to do this. However for us there is a code freeze at year end so we'll take the opportunity to do the upgrade in December.
Is it a coincidence that the LTS and STS releases are in November and not January?
Your team maybe can benefit using some handy tools like Renovate/dependabot, Central Package Management and Directory.Packages.props files
I'm jealous. I am in an erp ecosystem that has a major release every 6 months. Without a doubt there are there are always some breaking changes. Even the minor versions will sometimes randomly break things but aren't technically breaking changes. We spend more time staying compatible than ever before. We're at the point where we are thinking of hiring a Dev team responsible only for staying compatible.
Wow, sounds like a big failure if you need many men working for weeks just to change a version number from 8 to 9 on your csproj files and maybe update some NuGets with a press of a button in Visual Studio
Maybe your team can benefit of some handy tools like Renovate (or Dependabot) and Central Package Management (CPM) and Directory.Build.props. This could be really useful to speedup and make safe this kind of massive migrations.
From my experience, it's either draconian compliance or lack of automated testing that slows the adoption of new versions of dependencies. The better coverage and more autonomy (and accountability) you have as a team, the easier it is to move forward quickly.
A responsible of coverage and update dependencies here! Yeah, I totally agree with you. I introduced build validation policy (unit test have to pass always everywhere), diff coverage policy on Pull Requests and Renovate scheduled to update all dependencies. The life is just easier.
We don't hate it. We are just not done yet upgrading to 8.
Why not...?
@@JonasThente-ji5xxA lot of companies have dev resources prioritised towards customer requests and bug fixes as opposed to updating the framework constantly.
It’s a matter of time, resources and priorities, vs the benefits of upgrading and the risks of not.
@@discbrakefan Yeah, I understand that. But when a new .NET version has been released, and I'm working on something else in a service/application, I simply just update .NET and its NuGet packages at the same time. It takes like a few minutes.
I don't know why you would want to run outdated NuGet packages anyways.
@@JonasThente-ji5xx Do you not test anything?
@@bryanedds8922 I do. Just run the test suite.
Companies are upgrading? I swear most of the time it's still .NET Framework not even net core for most projects I've worked on.
Exactly. You are not alone; the .NET Framework is still present and will most likely remain in legacy projects for years to come.
Considering that .Net 9 is still not close to feature parity with .Net Framework, there are a lot of projects that want to use something more recent but are simply not able. We have a number of WinForms stuff where I work that are eager to update but not able to because no upgrade path exists.
For real. My last job the vast majority of the code was still running on Fw 3.5 - in 2023. A couple projects were on Fw 2.0. I asked permission to upgrade one _peripheral_ project to .NET 8 (LTS), they insisted on updating it to .NET 7 (out of support for several months) instead. Bosses don't understand the meaning of LTS releases.
You will laugh but in outsourcing the client's approval is the biggest factor in upgrading or not. You can give them the biggest list of advantages if they say no, it's a no. They will upgrade when they see the monetary impact of not doing it otherwise delay until needed.
Which is not a bad strategy most of the time... Devs need to touch grass. "Performance improvements" - even huge - in most LoB apps (most of the .NET world) don't make a difference at all.
Outsourcing the approval without clearly also outsorcing the risks that come with using unsupported versions is a clown show.
people saying LTS doesn't always mean that their company doesn't want to move to the latest version... but often it is a limitation of cloud providers like AWS. For example, you can't deploy .NET 9 Lambda to AWS, so AWS is dictating what version we should use :(
And other external Librarys are not net 9 ready 👍
Its never just a simple update. Not because of the compatibility but because nugets are deprecated due to security and you may want to use a new feature and that changes code
It would be much better if Microsoft upgraded .NET, C# etc. when they have a decent pool of worthy changes that make sense to upgrade to, instead of producing "something" every 12 months just to produce something. I don't have a problem in waiting 17 months for something new if it's worth it.
I don't think even the shareholders or analysts think that deploying something every year will raise/lower the stock price.
I would prefer them to have focus on runtime and languages in odd years, libraries in even years. There is lots of stuff missing that is simply there in Java.
@@McZsh Care to give some examples?
Company: Only use LTS.
Me: You can't see what's in my docker image...
It would be nice if LTS had 4 years support rather than 3, so that when time comes we could update to the latest version instead of an LTS that only has 1 year left. I.E. 6 to 10, 8 to 12.
You are not counting correctly
Literally upgrade our big ass wpf app with 300 projects, the day after .NET 9 release and manager was happy about the performance gains
I think that if Microsoft move to Forever support none will move to newer versions, leading to lack of engagement. Having all dotnet versions as LTS would be perfect
I find value in both approaches. For internal applications that doesn't need new features or constant updating the Never-ending support fits perfectly. For Cloud based SaaS applications though performance benefits mean cost reductions which is the primary reason to upgrade.
People watching your channel is more likely to update to .NET 9 than developers that don't even update themselves if not forced by their boss/project.
Haha very true
Upgrading once a year just doesn't work for smaller teams. Sticking to an LTS rhythm is far more viable overall, esp when libraries you depend on might not upgrade as readily and cause issues.
What's the difficulty?
The obsession that companies have with releasing a new version every single year is insane. Not every single product or service needs a new iteration each year.
Our company intended to upgrade from 6 to 8 in January, but that plan got kicked down the road due to other requirements needing the developer resources. Now we are at the stage where we must get off 6. We're just having the debate as to whether it should be 8 or 9. Everyone agrees that the effort to upgrade from 6 to 8 or from 6 to 9 about the same, and that 9 offers some significant performance benefits, especially around memory.
So what's the issue? Given our track record of kicking upgrades down the road, if we went to 8 then we'd have 12 months to get off 8 when 10 drops, but if we were on 9 we'd only have 6 months. We've just agreed to go for 9 with the acknowledgement that the next upgrade window will be only 6 months. (People still have memories of the upgrade from 3 to 6 where we enforced the StyleCop rules across the board - hopefully 6 to 9 will be a lot less painful).
Delaying and then making big version leaps can be terrifying (and sometimes paralysing), due to potential breaking changes. This is possibly a good opportunity for you to push for more frequent and smaller version leaps in the future.
I didn't update our prod containers to net7 because 'not LTS', but all during that period we stayed on net6 we had to be wary of packages being updated and avoid any net7 specific updates. Broadly it's far easier to maintain packages on the 'latest' version of dotnet, even if that is an STS version. I don't think the STS/LTS distinction is too concerning personally. We started moving containers to net9 a day or two after release, and we'll try and maintain containers yearly regardless. I appreciate not all companies will be in a similar position with the freedom to move this fast though.
When looking at the poll responses, I think the .NET (core) community is staying updated quite well. With 18% still on .NET framework, the numbers for .NET core (70% on .NET 8, 7% on .NET 9) are quite impressive. That leaves only 5% on "other".
Java is up to 23, but it's not unusual to see projects stuck on java ~8 still. We have the same LTS issue; nobody wants to upgrade to something unsupported and tons of 'preview' features.
TBH, updating DOTNET version is A LOT easier than Java. Ive seen project that were stuck on specific MINOR versions of Jave, because of libraries emitting specific bytecode.
@@MagicNumberArg Its not 'libraries' it's hibernate. Every. Damn. Time.
We have the same excuses "but it's really not that bad once you get to 17!"
I think there is a good reason to update regularly, because the differences between versions are smaller and both testing and fixing issues are far more easy. I have landed several times in situations where the management thought upgrades would be a waste of money, but then the software became very unstable and we were forced to do a big upgrade project in a short time. This is very expensive.
I've voted .Net 8.0 in your poll. However, we do want to migrate to .Net 9.0 soon. Give it a few months and the survey will most likely have a very different result.
Why?
@@nezqwe4818 Why what?
it was just released and companies hate it already?
Believe him. We had a company developer meeting two or three years ago and managers and higher ups were in full agreement how much they hate .NET 9. We are still using pre adobe Cold Fusion for our finance and banking apps.
LTS vs STS. Companies we work for block us on 7, 9 etc
So “skipping because we only use LTS releases” equals “hate”?
Classic Nick clickbait.
Not hate, just can't keep up with the pace. This is fine for smaller companies and projects, but not for bigger ones.
@@troncek In smaller companies and projects it doesn't make sense either. It's very very rare to even need performance improvements so why bother.
It's not like there are some huge security holes in older .net versions.
For me, it was the complete overhaul they did of Blazor in version 8. I'm not going to argue one way or another on whether it should have been done. The fact is that they did it and it's almost impossible to upgrade a Blazor server app. I've never had success with any of the upgrade methods/guides; I've had to rewrite each one from scratch.
In consulting, you only upgrade from one version to another when you get paid for that, I mean, you offer it or the client ask for that, but always by contract. And when starting a new project we always go for de latest LTS.
I actually disagree. I think you need to have the non-LTS versions so that new features can be tweaked/hardened with slight breaking API changes before they make it into an LTS release. Some issues you just don't find until thousands of people are using your code. Having a period of time where API's can be tweaked is a must. The whole point of LTS is that the code you are running has been running in production for an extended period of time with no issues. Our team uses the STS version for our apps, but we dont work on anything where peoples lives depend on our software. If I was making medical, banking, or govornment systems, I would be sticking with LTS.
The bigger issue which I have right now is that more often than not, when I encounter a bug in .NET (or one of it's many libraries maintained by MS), even if the version I am on is still supported, I see bugs get pushed and pushed and pushed and never fixed in the supported version... It's always punted to the next major version (or multiple major versions)... What is the point of having an LTS release if you aren't going to fix the bugs people report in it?
My experience is a bit different. I found a bug in Ef core, reported it on Github, and they fixed it in 2 minor versions. It took them around one month from the report to the fix.
I think you misunderstand .NET STS. The bar to introduce a breaking change is not any different than LTS. STS is not some place to test stuff and tweak, it is just as stable as LTS.
We will be upgrading to .NET 9 in January/February. We have a pretty large code base with several million lines of code. I performed the upgrade from .NET 6 to .NET 8 in March and we have decided to upgrade to STS versions as well so we benefit from the improvements as well as to make the upgrade steps smaller.
We do have some larger Blazor applications which we also migrated from Blazor Server to the new Web App model introduced with .NET 8 in the upgrade process.
It really helps to have unit tests on core logic, I guess. 😅
Just to add to this: The only real pain we have had was the negligence that Microsoft has regarding C++/CLI when it comes to newly released versions of .NET. We use that feature pretty heavily as we also have some old MFC rich clients that we need to integrate properly with our newer .NET code to not rewrite features in C++ as well.
You titles are getting a little click-baity. I'm all here for it. For future reference, words like "exposed", "destroys" can also be used ;-)
It is extremely hard to make a video clickable on a topic that generally sounds mundane but I think is very important, so the TH-cam algorithm is to blame here. I could have titled this video ".NET's Support Policy has a Problem" but it would be watched less. I'm 100% with you, but it's the game I have to play unfortunately.
@@nickchapsas No worries. I think most here are aware of the need to "game" the system, and your channel growing benefits us all as .NET devs.
@@nickchapsas 2 types of content creators: click baiters and ones you haven't heard of.
@@adambickford8720 Probably true. Lets blame Google for not having purely engagement driven promotion,
@@nickchapsas do NOT upgrade to .NET 9 before watching this video)))
Nick didn't answer the question "Why...". It's a matter of app distribution. What is the target audience of the application? If you have a website that is located in the cloud, then of course you don’t think about it and can grab the latest update. But if you distribute applications in the form of distributions, you are limited by which platforms your application will run on. And not every user is ready to install new versions of .NET and not every operating system is compatible with new versions.
Hence, one of the reasons to use LTS is the maximum time for users to decide and prepare for updates.
Other reasons were also written by other users earlier in the comments.
I'm not upgrading to the STS versions. Can you honestly say that the new features of .NET 9 are enough over 8 to pay for costs of upgrade instead of going from LTS to LTS? Even if it's an hour per solution?
I'm 100% with you. Other than performance improvement, .NET 9 doesn't really have anything that interesting to jump on it.
I really like .NET release cycle. the odd release allow them to try new things without a huge commitment.
My thoughts as a developer: Most important motivation to upgrade is to be within support from Microsoft to mitigate security vulnerabilities. If there is a security vulnerbility that won't be patched in an older version, the company is taking a risk. All other benefits of upgrading are less important to the business. Agree that LTS and STS is confusing to people in business outside the dev team. An upgrade has to be planned and that takes time away from the business getting features that they ask for.
Aside: Release schedule is good for dotnet. A release each year helps to reduce the number of breaking changes to fix and provides a better short term way to obsolete language features (if needed).
Yep, agreed, though I suspect they don't because it increases their servicing obligations. Debian LTS is at least 5 years, but I think Microsoft want to avoid another 'tyranny of forever-supported' situation.
I would be more interested in how many of them are using the version that are not supported etc, would have been a better question on the survey.
I have control when to update Dot Net versions.
Started a new project on Dot Net 9.
An older project was upgraded from Dot Net 5 to 8 only last month, only because I was adding new functionality to it.
Still have application in Classic ASP, Dot Net Framework 4.x, Dot Net Core 3.1, 6, 7 and 8.
Eventually all the projects will be upgraded to latest version of Dot Net when request come in for new features, otherwise they will just sit there happily running.
Just for reference, these are all internal applications.
I recently moved all our code to .NET 8 from Framework 4.8. That was some work! To go from 8 to 9, I'm expecting, is to simply run the upgrade tool (I am an optimist :) ), so when things slow down I'll do that.
Generally speaking, we upgrade versions at or near release of the newest version because it offers some compelling new feature that either drastically simplifies our code (generic arithmetic in 7, for example) or offers us the potential for significant performance boosts (params spans in 9, and something in 8 that I can’t quite recall).
But we have the benefit of being an indie developer, so recompiling our libraries genuinely does come down to updating the project file, adding support for the new features we’re targeting, and recompiling.
I like the fact only even numbers are LTS. Upgrading things every year sucks, even if its quick.
It is not always as easy as just upgrading the version in csproj and dockerfile - you also need to make sure that all libraries you depend on have done the upgrade too. And sometimes upgrading a library may require jumping to the next major version which may have breaking changes. It is not a showstopper, just one of the reasons to postpone the upgrade a bit. To the time of release of .net 9 we've just completed the upgrade to 8th; we can now plan the next upgrade some time next year.
I do not mind STS and LTS system. STS can be when a new feature is introduced and a distilled version comes into the LTS. But, 3 years is just too short for LTS.
If you simply upgrade the version but do not refactor the codebase to apply the new features your codebase become harder and harder to read as the newer styles start to mix with each other and your codebase becomes less coherent.
Hard to sell why we have to do an upgrade every 3 years. Go changes less, and people really start to think it is less hassle with the upgrades as it changes less. The Course of creating an interpreted OO language and then try to make it compiled and functional.
If you're in a regulated industry, upgrading isn't just changing the number. It requires serious regression testing
Personally, in the industries I am and have worked in, clients simply will not consider running on anything but the LTS version _unless_ there is a *major* bug or critical vulnerability found in the current LTS version that is fixed in the newer release (and even then only in rare circumstances as the security exception process is... onerous). This applies to basically every language, library, and framework, not just .NET, and is written into the contracts.
I used same approach for over a decade of software development: use LTS, migrate to LTS. Meaning migration between versions on every 18-24 month. Thats not only about .NET this approach I prefer to use as common standard. Such approach allows to find balance between new feature expansion (CapEx) and Maintenance (OpEx) budgets. Stakeholders of projects are more negotiable to spend time onto maintenance once they don't hear every couple month about of upgrade and also its allows to keep development team balanced as project never falls into un-upgradable legacy void-hole
I agree fully in that MS should drop STS and only offer an LTS releases for every major release they make, like you said they have the capability. That being said I also truly think that a platform like HeroDevs is not something good for the community. As developers, we should look to new versions to get access to benefits, allow new junior developers to not have to work on legacy code they way many of us have and in general look after the systems we build. If it's so hard to upgrade your system to a new version you have something fundamentally wrong in your company. It can be tight or unreasonable time budgets over and over again, a leadership who doesn't understand the development cycle or simply put an understaffed team. All of these things is something you should reflect upon as a company. I've found myself in this exact position.
Now I do also think that MS has not traditionally made it easy to upgrade between versions (think framework days and early core version). Later versions are absolutely much easier to move between but I think something more closely to what Angular is doing with automatic migrations and a clear migration guide between versions would really help the community.
We don't really have policies for when to upgrade. We have apps ranging from Framework to .NET 8.
When a new version releases and I'm currently building a .NET project, I adopt it immediately. Otherwise, it just stays on whatever was the newest .NET version when the project was finished. I rarely get the time to touch finished projects and I would need a supervisor's approval because they have to figure out how to bill it or if it's covered by a maintenance contract.
We use only mature, LTS frameworks, libraries when possible. Moreover BOM and vulnerability reports are required.
I am currently migrating a .NET 4.8 server app to .NET Core. I am glad that my company gave me the freedom of choice, so I took .NET 9 and it is working fine so far. Question for Nick: Do you have a Aspire course on your site?
Usually upgrading is an easy as changing an 8 for a 9 in the project file. But most developments are done by outsourcing and they do not know where are the project files.
To be honest we updated to .Net 8 like 6 months ago.
We kind of got screwed when we updated to EFCore 8 by them changing query generation to convert something previously would generate a WHERE IN, to an OPENJSON.
They (Microsoft) say the performance penalty for OPENJSON is not that bad. Our experience begs to differ.
The only issue I foresee with us switching to .Net 9 right away is really just putting everything else on hold and hoping all our nuget packages still work after the change.
We probably will do it eventually. But we may wait a few months first. Besides that, there will probably a few performance and security patches for .Net 9 anyway.
Microsoft tends to have it's users be part of it's extended qa team. We will wait till things are a little more stable.
For us, when I upgraded to .net 9 our back-end didn't transfer as smooth as I expected and I had to rewrite some of the IQueryable linqs because for some reason the EF wasn't able to translate them same as it did in .net 8 and I didn't feel confident enough to greenlight it if it broke some queries already.
As for MAUI, they broke layout for Android and I'm no longer able to set it and it's always no limit, so I wait until they fix their issues with .net 9 first
we had a similar problem upgrading from net 6 to net 8.
I guess is the same problem, they updated the compatibility version for sql server, changing the queries generated, and if your database is configured in a lower compatibility version number the querys will not be recognized.
you can change that with 2 lines of code tho, no need to change the IQueriable expresions
It's understandable not to upgrade to STS if you don't plan to upgrade your project. But experience shows that upgrading multiple versions at once is always a huge leap. It's often easier to make small steps.
However,, sometimes you are blocked by a library that prevents you from upgrading. That can be a problem hrad to deal with, and having choosen an LTS version in that particular case may be worth it
If .Net went to a full LTS model, cloud providers (AWS) likely would support them and I could (easily) upgrade to odd numbered versions as well.
As of today, .net 8 is supported until Nov 2026 while .net 9 is supported until May 2026. Why should someone upgrade an enterprise project to .Net 9? I agree with you that if Microsoft wants people to upgrade, they should extend the support and all versions should be LTS. At the same time, I also want to say that some of the features for cloud native apps are not immediately supported. For example when we moved from 6 to 8, we only had isolated model for Azure functions project. We had to do code changes, the hooks to azure events changed the way they operate etc. So it is not about .Net runtime alone. It is also about cloud support for the runtime.
Reason to upgrade, security. Those that use unsupported .Net versions are opening themselves up to being hacked. New vulnerabilities are being found every day. I'm all for using supported older versions, until the lifecycle ends and support from Microsoft ends. Then it's really time to update. Not doing so opens up your company and its employees to being hacked.
We cannot run out of support software. LTS support is beyond the next release's support date, so best for us to just update on LTS versions. NuGet Manager in Visual Studio tries to push staying on the latest, which is problematic with wanting to stay on LTS only versions.
If all releases were LTS, then we would probably update to latest to minimize updating pain. We are still migrating 4.8 framework code to .net 8.
In my opinion having the sts version is important since the technology is a advancing very rapidly and you need your favourite language and framework to keep up . Imagine if we are forced to wait 3 years just to get the IChatClient that deals with any AI model in a very standard way in a world competing over maximising the use of Ai in thier apps. Another important advantage is the simplicity of migrating from lts to sts and then from sts to the next lts, if we didn't have the sts then I imagine the upgrade from one lts to another lts will take much more effort.
I wouldn't mind them keeping STS and LTS if they'd extend LTS to 5 years.
I think this question, about what people are running in production, has been asked too soon. There are still plenty of packages that are in pre-release mode pending final QA, and some of them depend on pre-release of Microsoft packages as well. I'd start the upgrade to .NET 9 in a heartbet for all our projects, but right now it's more of a hassle than its worth, so I am delaying that upgrade a few weeks to let the package ecosystem stabilize around .NET 9.
Yeah, I never upgrade until after the new year. I also don't usually release the upgrades until there is a business need to release them. If there is no business need, then there is no reason to risk potentially releasing an unnoticed breaking change.
AWS support LTS only for their lambdas. So now you are tied to a third party vendor
100% agree with this. For agres I have seen people not upgrading primarily because of the support model. And for other valid reasons such being too frequently or being too much work, that is only true if you are not accustomed to. it's like CI/CD, instead of fear of merging (or in this case upgrading) you just do it more frequently until is a no brainer. The benefits almost always outweigh the costs.
It doesn't have to be an all-in-one upgrade either. You can start bumping the .NET version and upgrading nuget packages, later you can use more C# syntax and also newer framework features.
We've upgraded already. There are issues with Rider, but otherwise looking good so far.
It is going so fast … we have 100+ applications and if we want to upgrade them every year we will be busy just doing that 😅
I think bigger problem than LTS or STS is support in different hosting platforms. I don't believe that their own Azure is supporting all services with .NET 9 version already. For example Azure Function were not properly supporting .NET 7 for very long time and i think .NET 8 was released before they fixed those issues for .NET 7 and it's nothing worse than figure it out those issues when you already updated everything and you have to revert everything back.
1:13 "Thousands of .Net microservices" is that a figurative speech? Order of magnitude figurative?
Nop. It was 1000+. When I left the company was the 9th most valuable private startup in the world
@@nickchapsas Are you saying that 9th most valuable company justifies 1000 microservices? I do not think there is a single use case in the world where a company would want a system made even of 500 microservices.
@@tridy7893 Payment Gateways are EXTREMELY complicated systems. By far the most complicated system I've ever worked with
For context MS, Amazon Google etc have tens of thousands of microservices
@@nickchapsas I could not find any statistics about how many microservices an average project within any of the tech giants have. I do not think that how complicated a project is has to do with the growing number of microservices. The amount of work that needs to be done to support a system of even 50 microservices will increase the cost of the project significantly. In my opinion, when I see someone says EXTREMELY complicated, it really smells like chaos and lost control. Payment gateways can have many volatilities but if there is a separate microservice per payment type, per customer type, per region, per timezone or similar (if you can say what made the project grow to such a large number of microservices, please let me know), then there is probably something wrong with the design. I have not seen the designs of the projects of any tech giants. But again, what they are doing does not necessarily mean that they are doing it properly. Why would you want even 50 microservices in a project? What do they all do?
If every release were an LTS with 3 years of support, we'd always have a mix of the latest version (new or recently updated code) the version release 2.0-2.9 years ago (everything else). End of life is an incentive to update.
Too clickbait-kind title, .Net9 was just released. And I don't hate anything (except maybe such titles), but I tried to migrate my project, one show-stopper bug in EF Core, one in Blazor. So I will wait, quality goes first.
yeah I am also waiting mor EF Core libraries I use to catch up and release a .NET 9 compatible version.
the only stopper for me currently is waiting for other dependencies to update if they have to
What was your EF bug? I found one to do with how the EF parses child queries. I.e in EF9 it doesn’t pre-parse them whereas in EF8 is did. Which was an issue all the way back in EF6, I.e pre .Net core.
@@PaulPendor Ticket 35110, title Unexpected PendingModelChangesWarning on initial creation of database via migration
Many companies also have code freezes close to release of new .NET versions - and are often racing to get other changes out before said freezes. It's possible some of this is accounted for by lack of ability - be interesting to compare in the new year
Did you really create that poll so soon after the release and expect a different outcome?
It should be company policy to upgrade to the latest versions as they come out… upgrades become harder and take longer the longer you wait… that’s a $$$ risk for a company… therefore, all companies should enforce adopting the latest version sooner rather than later to protect their bottom line.
.Net 8 supports ends in November 2026
.Net 9 supports ends in May 2026
Oh noooo!
So you have a 6 month window to get off a STS version once the next LTS drops and 12 months to get off a LTS version.
It's not like all apps on those will spontaneously combust after that date
@@oussama7132 Yes they will. They didn't tell you?
Versions are extremely stable on initial release anyway, so I don't really stress about that
@@steve-wright-uk Considering migrating is trivial at this point there's no point to compare STS to LTS now. It makes more sense to compare .NET 8/9 to 10.
As someone that only takes the LTS versions (and keeps up with them); I like the STS / LTS model as I'm only getting updates every other year; but there is in the wild, field tested mid-release version (STS) that came between; so while I take on growing pains every two years; it isn't a flat "oh this has been in development without people using it" two-years ... so generally like this current release / support model.
I do hate .NET 9 primarily because the removed "Extension everything" right before publishing.
All of us 🥲
I don't know what that is. Was it supported in .net 8? If not, that's not a good reason to hate 9.
@@tonyhenrich6766 It was an amazing feature they were going to add. It's a pretty good reason to hate .NET 9 for this.
@@fusedqyou Maybe they didn't have time to implement it fully. I don't subscribe to the idea I hate a product because they didn't add a feature to it vs an existing feature that doesn't work right or gives me grief.
Our biggest project is sadly still on .NET Framework, everything else is on 7, going to 8 in a few months, just hasn't happened yet because too many other things having to get done
This is not this.... the problem is always money...
-"I would like to highlight the need to upgrade our systems to ensure its future functionality, compatibility with surrounding environments, and long-term sustainability. The system is a vital component of our operations, supporting [specific function, e.g., resource booking, data collection, etc."
-"But It works? Dont need that we will buy something on the shelf"
silent -" that never happens..and it wont work"
We stil have a descent amount of classic asp and some webforms.
We only upgrade to LTS releases. It can take over a year for us to upgrade versions because of how slow our process is, how few resources we have and how legacy our applications are.
So for us, it really doesn’t matter, we wouldn’t upgrade every version no matter what MS does.
Still moving from 6 to 8 while also migrating Azure Functions from "In-Process" to "Isolated worker" model which adds a little more work than just changing 6 to 8 in csproj/fsproj
Oh and there is regular work that has to be done on top of just "updating" stuff...
Microsoft needs to expand (probably double) their support lifetimes. Also their major version numbering thing feels wrong.
we had an issue with .net 7 and .net 8 because Microsoft changed the docker image ports from 80 to 8080 and tls 1.3
When .NET was 4 years old, new developers mocked me for sticking with Delphi. Now, the codebase I work with is still partly 32 years old ... and it just compiles. When I hear complaints about .NET, I’m glad the toughest migration I faced was switching from 32-bit pointers and ANSI strings to UTF-16 (internal format). In 25 years, that has been the biggest migration challenge. Of course, we still test new versions-because when you’re dealing with 9 million lines of code, chances are something will break.
“Till the sun explodes and kills us all” LMAO 🤣
I don't know why this wasn't discussed earlier and is being brought up now.
The 3 years LTS looks reasonable when we consider the goals with the new .NET. Yes the core problem is that there's not enough resources put on the .NET team (many features delayed, short support span etc), but let's not mind that for now, ofc longer support the better. But people often don't upgrade only because of NuGet dependencies that are not updated yet. This then chains on.
It's part of maintenance to check what is there to update, so there's a chance to check that there's .NET 9 and see what happens when you try to update to it. If it's too complicated, leave it on next LTS. But having up to date services is part of the job isn't it? The more you leave it be, the harder it becomes.
STS currently I agree is pretty tight and it would be better if it was extended by at least half a year.
I am a Lead Programmer, I was looking at upgrading to .NET 9 last week. But hit massive roadblocks due to lack of backwards compatibility with .NET 8 NuGets. For example, we couldn't adopt EF .NET 9 because we need Pomelo which was at the time of attempting (not sure if it is at the time of writing) not compatible with EF 9.0.x.
We have decided to revisit the upgrade after Christmas. Hopefully giving our NuGet Package developers enough time to upgrade to .NET 9 themselves.
Came across the Pomelo issue as well. Had to stay at EF Core 8, which works good for .NET 9, it doesn't really block anything else from upgrading. Breaking changes in it's core .NET 9 from 8 are not significant, unless you're using Blazor or something more fresh. Of course it gets worse with complexity.
going from framework 4.8 to .net 5 was the hardest move ever, so many missing features.
.net 5 to .net 6 was painful.
now with everything on .net 8 and will only be going to .net 9 when all the packages needed are there.
We have a LOT of dotnet applications from 6 to 8.
we don't care about Lts or sts.
I usually wait one month before migrating to new dotnet version and when there is new features or some security issues
making lts be 6 years instead of 3 will do for me (everything else can be left as is). at least you will be able to dig into a somewhat big project (2-3 years) and implement it while the lts lasts. it is really inconvenient to have people assigned for upgrading while the project is still not finished and is not in the support phase
Hot reload is fully broken in .NET 9 - I'm not going to upgrade till the tools are at least as reliable as .NET 8.
isn't .Net pretty much backward compatible since the .Net core 5 version? 'Migrating' to a newer version basically means installing it. IIRC they did change default boostraping fille/class (IIRC Program) in the version 6 or 7, but it didn't/doesn't break anything, old way of doing things still works.
We went full blast on .net7 and the .net8 upgrade was quite painful for a few projects, and I wish we had just stayed on .net6 for those.
Lesson learnt; wait for the next lts
the biggest problem in my company is not because LTS/STS model, but because of a mindset of "why should we migrate if it's still working? let's add some features instead of wasting time on migration". And any changes made by Microsoft will not fix this)
.Net 8 for the new services, .Net Framework 4.8 for the legacy coprolith and the user-side parts
Nick, I purchased your maui courses on dome train and I made an issue entering my email information. I can't access the courses. I've been reaching out to support without any responses. Can you lend a hand :X
Thanks for the support, guys. Much appreciated.
I think that a lot people are still on .Net 4.x because the upgrade path was / is non-existant and there was no support and no documentation to support it. So any products built on .Net 4x are likely still there. My main product is still there because of this. I desperately want to be on the latest .Net Core but I can't justify the time it will take to get there and the unknowns that will have to be overcome to get there. Microsoft's approach to the early .Net Core of it not being a full replacement screwed us big time. It would have been ok if at some point they said "Ok, now is the time to consider this "the next version" of .Net, everyone should upgrade and here is the support / documentation to do it", but that didn't happen as far as I can tell. MS just abandoned .Net 4x users.
I like the approach of getting new features every year. Waiting 2 years seems like a lifetime in the tech space. The tech will become irrelevant real quick as competitors snatch up the space with newer tech
I one hundred percent agree with you. MS should just drop the STS model and stick with LTS.
We are definitly upgrading to .NET 9.0 due to massive performance improvements and due to end-of-support for .NET 8.
Love this idea. I'm stuck on .NET 4.8 because that is the version that has the longest support ATM.
IMO I think their current cadence is fine. We will only run LTS (we are on 8). I don't have upgraditis & there isn't anything from version to version that i generally HAVE to have. Honestly if their were supporting LTS on every release it would probably push us to upgrade to something we really don't HAVE to have.
3 years for 'LTS' is IMO laughable form an enterprise standpoint. Then there's JS world with Node js with 30 months 'LTS' releases lol.
Personally: I still have a ton of old crap on framework projects (inherited a lot of legacy), which has priority to get to "core". Once that is done I'll think about also updating to non-lts versions. E: those projects probably will go directly to .net 9, because doesn't matter, but the stuff that's on 8 now will stay there for the foreseeable future (read: until 10 comes out probably)