Why Developers and Companies Hate .NET 9

[@dalemac89]

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.

[@0xF81]

Meanwhile my corporation still using WebForms released in 2002

[@coolstorybrooooo7643]

The real OG's

[@nickchapsas]

WebForms was ahead of its time

[@ВладиславДараган-ш3ф]

Run

[@randypenajimenez3893]

It works fine, a lot of banks around the globe use it

[@okmarshall]

@@randypenajimenez3893 Banks using it is not necessarily a good endorsement for the technology.

[@JoeStevens]

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.

[@JonasThente-ji5xx]

It's trivial to update

[@mosukiton]

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

[@ray89520]

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.

[@datoon83]

​@@JonasThente-ji5xxthat depends... Recently updated a load of azure functions from .net 6 to .net 8 - not trivial...

[@discbrakefan]

@@JonasThente-ji5xxThat is a blanket statement. It may be trivial for some teams/companies/apps, not so trivial for others

[@kaseywahl]

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.

[@steve-wright-uk]

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?

[@GioacchinoPiazzolla]

Your team maybe can benefit using some handy tools like Renovate/dependabot, Central Package Management and Directory.Packages.props files

[@mattymattffs]

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.

[@JonasThente-ji5xx]

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

[@GioacchinoPiazzolla]

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.

[@stephanf17]

We don't hate it. We are just not done yet upgrading to 8.

[@JonasThente-ji5xx]

Why not...?

[@discbrakefan]

@@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.

[@JonasThente-ji5xx]

@@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.

[@bryanedds8922]

@@JonasThente-ji5xx Do you not test anything?

[@JonasThente-ji5xx]

@@bryanedds8922 I do. Just run the test suite.

[@martinmayer4019]

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.

[@GioacchinoPiazzolla]

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.

[@turcanuioangeorge4750]

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.

[@AmonAsgaroth]

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.

[@adamblade9156]

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.

[@aprobinda]

Exactly. You are not alone; the .NET Framework is still present and will most likely remain in legacy projects for years to come.

[@maskettaman1488]

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.

[@gctypo2838]

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.

[@kaiserbergin]

Company: Only use LTS. Me: You can't see what's in my docker image...

[@T___Brown]

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

[@alirezanet]

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 :(

[@rookieew]

And other external Librarys are not net 9 ready 👍

[@ivancavlek4755]

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.

[@McZsh]

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.

[@dimitar.bogdanov]

@@McZsh Care to give some examples?

[@fotisspatharakis4310]

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

[@carlosmunozrodriguez]

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.

[@MagicNumberArg]

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.

[@JonasThente-ji5xx]

You are not counting correctly

[@yeahdima]

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.

[@arztje]

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.

[@JonasThente-ji5xx]

What's the difficulty?

[@Rafa_informatico]

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.

[@JonasThente-ji5xx]

Haha very true

[@paulguk]

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.

[@steve-wright-uk]

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).

[@paulguk]

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.

[@ericveltman5624]

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".

[@HollandHiking]

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.

[@butcher2709]

Literally upgrade our big ass wpf app with 300 projects, the day after .NET 9 release and manager was happy about the performance gains

[@adambickford8720]

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.

[@MagicNumberArg]

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.

[@adambickford8720]

@@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!"

[@justinian.erdmier]

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.

[@sikor02]

it was just released and companies hate it already?

[@JoeMancini-n9x]

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.

[@georgepagotelis]

LTS vs STS. Companies we work for block us on 7, 9 etc

[@jkdmyrs]

So “skipping because we only use LTS releases” equals “hate”? Classic Nick clickbait.

[@troncek]

Not hate, just can't keep up with the pace. This is fine for smaller companies and projects, but not for bigger ones.

[@AmonAsgaroth]

@@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.

[@jmmoyadev]

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.

[@chaws314]

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?

[@tNRevan]

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.

[@TheMikernet]

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.

[@sunefred]

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 ;-)

[@nickchapsas]

It is extremely hard to make a video clickable on a topic that generally sounds mundane but I think is very important, so the KZbin 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.

[@sunefred]

@@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.

[@adambickford8720]

@@nickchapsas 2 types of content creators: click baiters and ones you haven't heard of.

[@sunefred]

@@adambickford8720 Probably true. Lets blame Google for not having purely engagement driven promotion,

[@happy_burger]

@@nickchapsas do NOT upgrade to .NET 9 before watching this video)))

[@JPDev70]

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.

[@owns3]

I really like .NET release cycle. the odd release allow them to try new things without a huge commitment.

[@robertbrown7478]

“Till the sun explodes and kills us all” LMAO 🤣

[@TheJambo51]

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.

[@Lothy49]

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.

[@allenn9068]

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).

[@UweKeim]

I do hate .NET 9 primarily because the removed "Extension everything" right before publishing.

[@nickchapsas]

All of us 🥲

[@tonyhenrich6766]

I don't know what that is. Was it supported in .net 8? If not, that's not a good reason to hate 9.

[@fusedqyou]

@@tonyhenrich6766 It was an amazing feature they were going to add. It's a pretty good reason to hate .NET 9 for this.

[@tonyhenrich6766]

@@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.

[@qwer1234cvb]

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.

[@dynosophical]

If you're in a regulated industry, upgrading isn't just changing the number. It requires serious regression testing

[@hemant-sathe]

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.

[@myroslavberlad4428]

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

[@mrkapowski8507]

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.

[@tedchirvasiu]

.Net 8 supports ends in November 2026 .Net 9 supports ends in May 2026 Oh noooo!

[@steve-wright-uk]

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.

[@oussama7132]

It's not like all apps on those will spontaneously combust after that date

[@stoched]

@@oussama7132 Yes they will. They didn't tell you?

[@gileee]

Versions are extremely stable on initial release anyway, so I don't really stress about that

[@fusedqyou]

@@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.

[@mistalan]

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?

[@Krilllind]

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.

[@Ankh.of.Gaming]

Bruh, .NET Framework is still alive and well.

[@herrquh]

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?

[@nickchapsas]

I'm 100% with you. Other than performance improvement, .NET 9 doesn't really have anything that interesting to jump on it.

[@jk_code]

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. 😅

[@jk_code]

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.

[@LordCoon159]

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.

[@carlosmunozrodriguez]

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.

[@zbaktube]

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.

[@LasseVågsætherKarlsen]

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.

[@evancombs5159]

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.

[@GackFinder]

If going from 8 to 9 is mostly just changing a number, then the effort of going from 8 to 10 vs from 9 to 10 is literally the same. Ergo: No benefit to go from 8 to 9.

[@PticostaricaGS]

Good to see less than 50% are on classic .NET Framrwork. As for lack of immediate upgrades, it also reveals lack of strong best practices like strong Automated Testing.

[@denissorn]

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.

[@BigBang1112tm]

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.

[@jakubjasan8897]

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

[@hck1bloodday]

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

[@91loumac]

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

[@mciejgda88]

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...

[@tridy7893]

1:13 "Thousands of .Net microservices" is that a figurative speech? Order of magnitude figurative?

[@nickchapsas]

Nop. It was 1000+. When I left the company was the 9th most valuable private startup in the world

[@tridy7893]

@@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]

@@tridy7893 Payment Gateways are EXTREMELY complicated systems. By far the most complicated system I've ever worked with

[@nickchapsas]

For context MS, Amazon Google etc have tens of thousands of microservices

[@tridy7893]

@@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?

[@warny1978]

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

[@F1nalspace]

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.

[@chrishdog3]

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.

[@kridselot7383]

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.

[@waitingforyou2082]

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.

[@DevelTime]

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.

[@syzuna_]

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

[@PaulPendor]

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.

[@DevelTime]

@@PaulPendor Ticket 35110, title Unexpected PendingModelChangesWarning on initial creation of database via migration

[@lajoskemeri7728]

We use only mature, LTS frameworks, libraries when possible. Moreover BOM and vulnerability reports are required.

[@lucaswhite12]

"Hi, my name is Nick Clickbait and what I have for you today..."

[@WileeRunner42]

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.

[@AlexanderEndless]

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.

[@CuriouslyContent]

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.

[@tbgelectr0]

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.

[@gveresUW]

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.

[@SpaceShot]

You said it... STS is not a "preview" or "less stable". Based on history (not just what is written), there is no evidence that newer features are held for odd numbered versions. Key new features that are paradigm shifts (such as "Blazor United") show up in even numbered versions. Personally,.. I think we're in an era where you need a strategy to keep up. And that's not just for .NET... but everything you've chosen to build on. I see security patches and CVEs just completely ignored for years. But that said, I think many organizations are making it a flat policy to skip the odd releases to their own detriment and the policy makes that easier to justify.

[@CutieHoney]

I'll be upgrading all of the services I support to .Net 9 early next year.

[@frankyboy4409]

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)

[@josh1515]

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.

[@erichamion]

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.

[@lykeuhfox4597]

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.

[@zzing]

We just upgraded to 8, i expect two years before we see 10

[@Erik_The_Viking]

We just upgraded from ..NET 6 to .NET 8, and it was only because if it being EOL'd. We're spending more time dealing with dependencies, cybersecurity audits, and much more support work and by the time we're done it's now time to upgrade - again. If it works, don't fix it.

[@Cornelis1983]

Reasons are always the same: Money. Also, NES will always be Nintendo Entertainment System for me.

[@nickchapsas]

I was thinking the exact same thing!

[@br3nto]

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.

[@magusware8721]

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.

[@BigBang1112tm]

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.

[@DmitryV_HF]

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.

[@TedFanat]

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)

[@davidingleby6115]

Being a one-man shop, I have the luxury of rapidly upgrading. I do not use the luxury moniker lightly, it really is very good.

[@ryankueter9488]

Microsoft’s desire to limit their scope of support to the latest versions is understandable. Upgrading to the latest versions is ideal, from a technical perspective, because you not only gain performance benefits and potentially lower costs, but it allows you to compete with other companies who are integrating AI into their business apps. So, it would be foolish not to. The main reasons for why apps are never upgraded, from my professional experience, is 1) a lack of support from non-technical management and 2) a lack of understanding of a migration path that reduces the risk of failure to zero. This type of migration is possible. But the current teams/scrum process needs a slight change to make that viable in every business.

[@codefoxtrot]

The pitfall of the LTS and STS versions, is that once an LTS is released, by the time the planners and bean counters allot for this to happen, we end up upgrading to an LTS a year after it is released, which means the next STS has just become available. That next STS will be out of support, before the previous LTS is. And that's the problem with the model.

[@MitchelSellers]

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.

[@mctainshcom]

Love this idea. I'm stuck on .NET 4.8 because that is the version that has the longest support ATM.

[@wknight8111]

I stick with LTS at work but for personal libraries I multi-target all current LTS and the most recent STS versions. I always try to multi-target test projects, at work and at home, the same way so that I know we are always testing against most recent STS versions, in case the DevOps team needs to upgrade the PROD runtime for any reason. DevOps might make that decision but I won't choose to use STS in PROD, because I don't want to commit to all the necessary upgrade tickets within a given 18 month window. Upgrades may be cheap but they aren't free.

[@user-tk2jy8xr8b]

.Net 8 for the new services, .Net Framework 4.8 for the legacy coprolith and the user-side parts

[@Eddiegamer91]

My company builds out a model similar to what you propose microsoft does. We say "version x.4-z.0 ware now supported and each sub version drops support on a ticking clock from when it was released. We're still on web forms and .net framework. Our customers refuse to upgrade and our business doesn't make money from modernization features. I'm lucky enough to be the one developer given the allowance of 0 planning capacity to move us into more modern code base but the problem with the model is it absolutely neuters innovation and growth. It has made us lose well-qualified candidates because our code is so old and like 30-40% of the job is to take a feature on version z.0 and move it over to y.6, then regression test a whole bunch of things. I don't know the answer but I don't think it's that either. Then again microsoft is a leading force in modernization so maybe it's super easy for them

[@kailuaboy23]

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.

[@KurtisLininger]

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.

[@bobmartin9742]

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.

[@spechulfapticks3108]

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

[@ml_serenity]

We've upgraded already. There are issues with Rider, but otherwise looking good so far.

[@ahmedabd-a6]

As a team leader i am excited to update current projects to 9

[@vchap01]

Microsoft is trying to do the same thing as Node JS with the releases. But .NET by design is more stable and backwards compatible than the JavaScript/TS ecosystem so the model is suboptimal.

[@enji._]

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.