232. Why Do .NET Upgrades Happen So Quickly?

[@Cixelsyd32]

There is a big difference between encouraging people to upgrade and requiring it. 3 years is not a long LTS cycle, as a small business owner and solo developer I don't always have the time to upgrade especially when my software is stable. If I want to use modern cloud deployments however I am not left with an option to hold off. Microsoft could make things easier just by making the LTS support term longer. I don't care how often they choose to OFFER upgrades. I care how often they REQUIRE them.

[@IAmTimCorey]

There are a couple of things here. First, you can absolutely use the cloud using older versions of .NET. That's the beauty of containers. You can use containers to deploy basically any version of .NET or .NET Framework to the cloud. And, since you are using a container, the underlying OS won't be changing on you either so you are all set. The only concern is if that underlying OS or the .NET version you are using has a security exploit that you aren't patching because you don't want to do an upgrade. Next, let's talk about the "quick" three year upgrade cycle. No one loves it, but it isn't actually that bad of an idea. The reason why is because version maintenance is extremely expensive. Let's look at it another way - how many versions of your software do you support? Do you have multiple parallel builds that you continue to upgrade with new security fixes? For most companies, the answer is almost certainly not. Very few companies can afford to do that. Now you might suggest that Microsoft is a huge corporation, so they could afford to do it where you cannot. That is both true and false. Where does the money come from for .NET? Why does Microsoft build and support .NET at all? They get relatively small amounts of money from Visual Studio licensing. Where does the rest come from? From divisions that use .NET and from the promotion of using other Microsoft products (like AI and Azure). So .NET isn't really a place to make money directly, which means their teams are actually a lot smaller than you would expect. Trying to segment off those teams to support more versions would be nearly impossible. Then, let's discuss what happens if Microsoft did extend the LTS window. Let's say they choose 6 years instead of 3. Because of the difficulties of maintaining existing versions while building new versions, they would probably only put out a STS version every 3 years. Changes grind to a halt. Imagine the push to client-side development happening, but Microsoft not being able to introduce a tool to support it for six years after everyone else? Now imagine that the tool they release has been worked on, patched, reworked, etc. for six years before release. Do you think it would be a cutting-edge tool, ready to compete right away? Or would it need more work and time to coalesce? Probably the latter, which means another six years. Twelve years to get a solid solution is too long. Twelve years ago, phones were just starting to become the primary way to connect to the Internet. A lot can change in that time. 12 years ago, .NET Framework 4.5 was just released. That brings me to the next point - longer LTS windows mean larger upgrades. How difficult is an upgrade from .NET Framework 4.5 to .NET 9? Not really that easy. Now let's shrink your LTS window from 12 years down to 6 again. Six years ago, .NET Core 2.1 was just released. Razor Pages and Xamarin were the big deals, along with Visual Studio for Mac and the new Azure DevOps. Today, Xamarin has now been rebuilt as .NET MAUI, Razor Pages have mostly given way to Blazor, VS for Mac has been retired, Microsoft now owns GitHub and that's the primary place people do DevOps, and AI is now integrated in practically everything. That's a LOT to change. So do you know what companies would do? They wouldn't. They would stay where they are because their "software is stable". Microsoft knows this because they saw it happen over and over with the .NET Framework. So, they decided to make a change. Now, upgrades are MUCH smaller and while they happen every 2 years (with a year to get it done), they are much more likely to happen. One last thing - you said that this upgrade cycle was too fast for you as a small business owner. I would argue the opposite. I'm a small business owner. Until recently, I built all of the software our company needs. Now I have one developer on staff to do it for me and I don't do it hardly at all (for the company). We always upgrade to the latest version of .NET whenever we are touching a system. For example, the suggestion site (suggestions.iamtimcorey.com ) is currently running .NET 8. When we built it, I believe we did it in .NET 6. The upgrade process for this production app, which uses CosmosDB, Redis, Azure, SendGrid, and more, is extremely easy to upgrade. I just change the version number in the csproj files, I rebuild it, I download NuGet updates if they are important, I test the build, and then I publish. That's it. That process takes me about 15 minutes because I take my time. I'll do the same to it for .NET 9 when I get a chance. Bottom line: Microsoft doesn't require you to do any updates. You can run any version of .NET you want, even on Azure or other clouds. It is just wisest if you keep your app up to date for security reasons.

[@Cixelsyd32]

@@IAmTimCorey I usually like your videos but here you seemed to play MS Cheerleader rather than taking a balanced approach and looking at it from both sides. Yes, I could fully containerize but as of now I am in a code deployment using github actions to push to Azure App Services. Fully containerizing wasn't on my to do list either however. Azure and MS forced me to upgrade before it was necessary. I am not using a lot of third party dependencies and had no known vulnerabilities but .Net 6 Support ended and I had to make changes, whether that be upgrading to .Net 8 or containerizing, either way I was forced to make a change.

[@IAmTimCorey]

Not a MS cheerleader. I’m a consultant who has seen a lot. If you haven’t updated since .NET 6, you probably weren’t doing security updates either. Remember that 6 is the major version. There have been multiple updates to it to plug holes and fix broken elements. Updates are a part of life for developers. Are your users ok with no changes for years?

[@EricKing]

I agree with the commenter. 3 years of support is not "long term". Framework 4.6 had 7 years of support.4.61 had 7 years. 4.62 will have had 11 years of support by the time it's out of support. 4.7 is 7 years and counting. etc. I like the rate of change, but I think MS should support each version for longer. I get that doing so is more expensive for MS, but this less expensive support strategy only helps MS, and hurts their customers.

[@IAmTimCorey]

Actually, the shorter LTS window actually helps their customers, even if they don't always acknowledge it. By having a shorter LTS window, companies are forced to update their versions of .NET more often. Because they do that, they are more likely to be able to upgrade. Longer support windows means more breaking changes between versions. That makes it more likely that companies won't make the leap. Think of it like stairs. You need to get to the next floor up in a building. Taking one big step all the way to the top sounds good because you only have to do it once. However, there is no way you would actually be able to do it so you would be stuck on the current floor. Now you could put a flight of stairs there so that you could walk up. However, that requires you to take 12 or so steps. You might complain about all of the work that takes, but each step on its own is possible and the result is that you get to the next floor. That's what Microsoft learned from the .NET Framework's long support windows.

[@dattatreyapujar4068]

Appreciate your time and effort while making the video. .NET community owes you for all the work you do ❤

[@IAmTimCorey]

You are welcome.

[@raykoone]

I love quick releases as an individual, but not so much at work, would've loved if LTS was 5 years instead.

[@IAmTimCorey]

Thanks for sharing.

[@sglasgowaz]

And this is why you are actually smart. I am often confused how anyone in development does not understand these basics. But nice coverage Tim, and perfect timing based on the week. lol

[@sglasgowaz]

Also, it's really not that hard to pull a side branch or clone of your project to see how it works with the latest to see what the pain points are, or the benefits might be to stay up to date.

[@IAmTimCorey]

Thank you!

[@lolyasuo1235]

Who would imagine that .NET 6 is now EOL. A great version to develop things. They have started annoying me with how quickly things changes for no actual reason.

[@johnnyblue4799]

Indeed... too fast for no real benefits. We have a lot of overhead upgrading all projects...

[@IAmTimCorey]

There are absolutely reason why things change so quickly. I would highly recommend you spend more time investigating why.

[@RandomADGEJVF]

I'm happy with the upgrade cycle as most of my software needs little if any changes. What I do hate is spending a year and a half with NuGet suggesting I upgrade to 7,9,etc. Would be handy if they did a lts package so I'm only informed of upgrades to lts versions.

[@IAmTimCorey]

That's outside the control of Microsoft. For Microsoft NuGet packages, they typically change their major versions to be in line with the version of .NET. Not all of their packages do that, but a significant number do.

[@Otto-the-Autopilot]

@@IAmTimCorey That, and also their latest packages often still support older versions of .NET, even .NET Framework, too. So most of the time you could update your NuGet dependencies without having to also update .NET itself, if you wish to do so.

[@rvrunkillyow716]

​@@IAmTimCorey those packages should be part or aligned with framework upgrade?

[@sirgravacado4885]

Thanks for this. I had seen documentation on the life cycle of the .NET versions and couldn't understand why some versions ended their support before previous versions. That must have been the odd vs. even versions.

[@IAmTimCorey]

You are welcome.

[@faisalalhoqani6151]

Great episode dear Tim, I feel if they make it every two years it will be better than making a new version every year, the same for STS to be two years and LTS to be six years.

[@IAmTimCorey]

I'm going to do a video on support windows and why longer LTS windows are actually a bad thing.

[@Mac_okee]

The problem is not me, the developer. And dependencies are also not the largest problem. The biggest problem is the customer. For me it is always very difficult to explain why he has to pay for an update every year that he is NOT SEEING. He wants to spend his money on new features and not on updates that at first glance have no advantage for him.

[@IAmTimCorey]

I get that. I dealt with a lot of customers like that. I would give them a couple of pieces of information, which typically helped. First, I would ask them what they get out of paying for insurance. Security updates are important. Second, I would point them to the speed improvements every new .NET version brings. For example, .NET 9 makes loops more efficient. Loops. As in, the thing that every .NET version uses all the time. Just upgrading to .NET 9 will give you those improvements (and LOTS more). Every year, there is a published article that goes through these performance improvements. Here is this years' article: devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/ Third, I use the oil change analogy. What benefit does the driver see when they get an oil change? Yet the benefits are there. Also, the dangers are there if you don't get an oil change, even though you cannot see them and you cannot know when problems will arise. This is where being a consultant helps. I've seen the results of dozens of companies that ignored this advice. I've seen them struggle to find developers to maintain their systems. I've seen them have significant problems trying to maintain their systems. I've seen systems fail because of lack of maintenance. I've seen companies that have paid millions of dollars to recreate systems because they no longer had the ability to make their existing systems work.

[@lolyasuo1235]

He is right. There is no point to upgrade (and pay) every year. It is like buying a new car and trying to upgrade/replace it in next 2 years. Just why?

[@Otto-the-Autopilot]

@@lolyasuo1235 And for those customers, go with the LTS versions.

[@rvrunkillyow716]

What are those sample dependencies you are talking about here sir? Just to have an idea.. thanks in advance.

[@IAmTimCorey]

Are you asking what an example of a dependency might be? If so, that would be anything that you install via NuGet. For example, you might use a Telerik UI library or you might use the StackExchange.Redis package or Dapper. These are all rather stable examples, but that gives you an idea. If you find a random NuGet package from a developer, you might find that it works great now but that developer isn't going to keep working on it. Now your app relies on that package, but that package doesn't support the new versions of .NET. If it is open source, you can potentially fork the package and create your own version. However, that's not a common option.

[@rvrunkillyow716]

@IAmTimCorey wow, you answered exactly what im trying to ask sir.. thank you for that.. plus a bonus advice which open up new knowledge for me..i realized there are a lot to consider regarding adjustments on upgrading.. im glad you tackled it sir.. 🙏 a bit scary to be honest.😅

[@adrian_b42]

I am working for a large manufacturer with each app installed in over 100 different plants. Stability is key, security is not a problem (network segmentation for operational network). We upgrade the apps only for new features or bug fixes, ideally we should never be forced to upgrade anything that works fine, even 10-15 years later. Upgrading dotnet is a major pain, this stuff is regulated and we need to go through a very long, complex and expensive testing and validation process for every single app. This is where Microsoft is wrong and they know it, they approached us to learn more about this area they want to dive into. Standard support in this area is 5 to 10 years, LTS is 10 to 20 years. What you explained in this video is correct, just does not apply to some cases.

[@IAmTimCorey]

I'm not sure what you are expecting here, though. If you are on an air-gapped system where security is not a problem, you don't need to upgrade. Microsoft isn't forcing you to upgrade. You can use one version of .NET for as long as you want. You won't be supported by Microsoft, but I'm not sure what you are expecting from that support. That support means that they will fix bugs in .NET and address security issues. If those two aren't an issue for you, you don't need to upgrade and you don't need support. You can run on .NET 6 practically forever. Just make sure to include .NET when you do your installations so that you always have the correct version on the client. The issues will be more a matter of the world passing you by, your code will become harder and harder to upgrade if you ever want to in the future, and employees that want to work on your systems will be harder to find. You may need to freeze the version of Windows you have at some point, as well as the version of Visual Studio you use. You will also need to be sure that any third-party libraries you use are downloaded and served locally, since some will go away and others will remove support for older versions of their packages. In the world of software development, an LTS of 20 years is not possible. Think about it. 20 years ago, Windows XP was just out. Computers had Pentium 4s (32 bit processors were common) with 256MB of RAM. Spinning 5400RPM hard drives were common. You want software written in this era to still be supported today? How much are you willing to pay for that? From Microsoft's perspective, with a minimal team, you are talking about millions of dollars per year. Now, let's say Microsoft goes for it and you are using it. Now, 20 years later, support is up. What then? Are you going to upgrade to .NET 9? From .NET Framework 1? The incredible thing is, from Microsoft's perspective, you can actually do that, but I highly doubt you can physically do it. That means that your app is going to be out of support. The outcome didn't change. The only real difference is that it is more likely for the app to stay out of support this way.

[@adrian_b42]

@@IAmTimCorey I don't disagree with you in any way. What I am saying is that there are lots of places where upgrading every 2-3 years is too fast. I worked in an airport before, some of their systems were really old, but perfectly adequate. Yes, when you upgrade it is likely it will be to a new OS version and a lot of dotnet versions newer. Yes, many developers like to be on the latest and greatest, but there are very good money to be made with ancient languages (ex: fighter avionics, F16 is older than me and still very popular) and I see nothing wrong there. And yes, we pay Microsoft a lot more than millions for support of old stuff and it is cheaper that way. So, you are perfectly right, just don't forget about the significant portion of use cases where LTS is too short. Why do I say that? Because when we need consulting, people like you are on the list to ask for it. But if you are not aware of this kind of clients and their general perspective, you might not be able to understand them well enough to help them.

[@IAmTimCorey]

OK, so I get what you are saying. You aren't really advocating for a longer LTS as much as a longer extended support contract window. Yep, I can see that. The issue is it really is a custom thing. It should almost be treated as a separate language at that point. There is so much that goes into super-long support windows like this. They are necessary, but difficult to get right.

[@ericritter46]

I would love it if you would do another touch on the whole VS code versus Visual Studio Community and the licenses. I'm still a bit confused on the whole 'can I build apps on Visual Studio Community". I know I can, but what are the actual imitations since I don't buy the pro or enterprise licenses? Should I switch over to VS code as a solo developer or continue to use Visual Studio Community?

[@IAmTimCorey]

Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/ I can definitely cover that topic. A quick answer, though, is that if you qualify for a Visual Studio Community license, you can use it commercially. You are set. The way to qualify is to ensure you make less than $1,000,000 annually as an individual or company and, if you are a company, to employ 5 or less developers.

[@codefoxtrot]

Two things: 1- Don't wait until 10k miles to change your oil, it's the lifeblood of your engine. Also keep an eye on your coolant level too-- you'll want to know if you're leaking coolant! As for .NET, an additional consideration not mentioned here is your cloud host provider... what .NET runtimes versions do they support, and when do they stop hosting a particular version? You need to know that. Sure you can sit on .NET 5 if you're running out of a local data center, but not so much if you're on a hosted cloud provider! Definitely take their support timelines into consideration. Ohh, and change your oil! Do it now! Check all the fluid levels! RTFM!!!

[@Otto-the-Autopilot]

As a matter of fact, you can, at least within Azure (App Services/Azure Functions) itself, easily still run an application that is on .NET Core 3.1. You will probably get warnings at some point, but it keeps working.

[@IAmTimCorey]

Just FYI, the manual says every 10,000 miles for her vehicle ( rav4resource.com/toyota-rav4-oil-change-interval/#official-recommended-intervals ) So yes, I did RTFM. 😄 As for cloud hosting support, that's not really an issue if you are prepared for it. With the advent of containers, you can host any version you want without issue. Even for non-containerized applications, you can deploy the correct version of .NET with them to enable them to work even when the version is "not supported".

[@MA-kt8ly]

Just when our system stabilises, we are forced to upgrade.

[@IAmTimCorey]

No one is forcing you.

[@Dimitris.Christoforidis]

I think that the problem with frameworks is that you also need to install also new net9 for windorms or net9 hosting bundle for api. So we need to upadate expect our software all dotnet frameworks

[@IAmTimCorey]

I'm sorry, I'm not sure what you are saying is the issue. Are you saying that the problem is that you need to install .NET 9 in order to use .NET 9?

[@Dimitris.Christoforidis]

@IAmTimCorey Yes, if it was embedded in windows 11 it will be easier

[@IAmTimCorey]

No, that’s a problem because then your apps mess up if Windows updates. You can pack .NET with your app so you aren’t dependent on the right version being on the target machine.

[@swordblaster2596]

In the real world, platform stability is an extremely valuable thing. Also, advancing things all the time is an extremely valuable thing. I don't think MS currently have the balance correct, and this is because I skew much more towards platform stability being the most valuable thing. 3 years is in no way a reasonable "long term support". Try tripling that.

[@IAmTimCorey]

When you triple that, you have massive updates. What things might change in 9 years? Just six years ago, Xamarin was the big new thing, VS for Mac was added, and the biggest update in ASP.NET Core was Razor Pages. Now, Xamarin has been deprecated and replaced with .NET MAUI, VS for Mac has been deprecated, and Razor Pages are a minor footnote in ASP.NET Core compared to Blazor. The point here isn't that things are just changing. The point is that moving your code from where it was even six years ago to where it needs to be today (if you considered .NET 9 an LTS and .NET Core 2.1 to be the previous, which is a 6-year span), would take a tremendous effort even with Microsoft's extremely hard work to not break things if at all possible. The result of that big of a hurdle? Companies don't do it. They stay on the previous versions. How do we know? Because Microsoft used to have a longer LTS schedule with the .NET Framework. .NET Framework 1 was supported for 7 years. Version 4.0 was supported for 12 years. There are still LOTS of companies on .NET Framework 3.5, 4, and 4.5, even though .NET is now on version 9. That's at least 6 years of production-ready, solid, reliable versions, even if you don't start counting until .NET Core 3.1. In your mind, companies shouldn't start moving to .NET until .NET 12? That would be roughly your 9-year LTS window. The danger of companies not doing security updates for years is incredibly high, yet companies decide that upgrades are "too hard". Instead of building more resilient systems that are easier to upgrade, they just decide that short-term benefits outweigh long-term consequences. That's how it works. So, Microsoft did what they could to encourage companies to make the shift. They made upgrades a LOT easier and they made the jumps from one version to another a LOT smaller with very few breaking changes.

[@alexisfibonacci]

At what cost?

[@KarenTazayan]

STS releases get free support and patches for 18 months not 15.

[@IAmTimCorey]

Yep, I misspoke.

[@aleksandarstanisic1848]

Its crazy...😢

[@IAmTimCorey]

Why?

[@keyser456]

When you amass the small army of developers and managers they've amassed, they have to justify their jobs. Change for the sake of change becomes a thing. You end up with 27 different syntaxes to do the same thing, and as a dev you can't learn just one of them. You have to be prepared to run into any or all of those syntaxes on any given team or any given project, so you have to learn every way of doing the same thing. As a rank and file developer, doing it all for a guaranteed paycheck on your employer's dime every week -- it's not so bad. You're making a good (sometimes _really_ good) salary while padding your resume. Even for established and/or larger companies with established products and large revenue streams, the costs of keeping up can be absorbed. As a small-business owner trying to launch their first project and get a foothold, it can be a nightmare. Even the LTS schedule is too short for any long-term projects for small companies. Those are the "some people" he casually brushes off in the beginning. The small companies that do make it aren't doing it because of this aggressive schedule -- they're overcoming that hurdle, albeit in smaller numbers.

[@johnnyblue4799]

The whole IT ecosystem is broken. They're coming up with new versions to create more business. The real advances in the language/libraries are not that many. It's technology for the sake of technology, not to solve real world needs.

[@IAmTimCorey]

I've addressed this in other comments, but I'm going to summarize a few points here. First, "change for the sake of change". That's an interesting claim. I hear it a lot, but people don't actually seem to be able to back it up. Which specific changes do you think are unnecessary? And remember, it needs to be unnecessary at all, not just for your specific and narrow use case. Second, which do you think is worse - adding an additional way of doing things or making a significant breaking change that will stop companies from being able to upgrade without massive changes to the codebase? Here is a quick example I'm actually going to do a video on: They added an overload to the TimeSpan.FromSeconds() method to take integers instead of just a double. The reason why is because of the imprecision of doubles. A double of 101.832 (101 seconds, 832 milliseconds) would actually come out as 101 seconds and 831.9999 milliseconds. Microsoft could have broken all existing applications by changing how the input worked, but instead they overloaded it to take seconds (and optionally milliseconds) as integers so that you could have a precise number. Third, the "cost of keeping up" has to happen either way. Are you saying that you don't upgrade your versions of .NET with the new security patches during the three-year LTS window? Because that's really the big thing here - you need to upgrade your version of .NET either way to get the new fixes for security vulnerabilities. Sure, the .NET versions also come with a few breaking changes, but if you are already making an update, fixing the breaking issues shouldn't be much additional work since most breaking changes are for a really good reason (like major vulnerabilities or because the functionality is obsolete). For example, .NET 9 has a breaking change of limiting a BigInteger to (2^31) -1 bits (about 2.14 billion bits). That's almost 256MB of memory. This is a breaking change because it used to allow Array.MaxLength * 32 as the maximum size, even though most systems would hit an OutOfMemoryException before they would hit that value. Fourth, these small upgrades make it easier for small businesses, not harder. I have multiple production applications. For example, I built the suggestion site ( suggestions.iamtimcorey.com ) using .NET 6. I've since upgraded it to .NET 7 and then to .NET 8 and, when I get a free 15 minutes, I'll upgrade it to .NET 9. That process is painless. It mostly involves changing a version number and upgrading NuGet packages. Sure, I might have a fix or two to implement, but those are almost exclusively because of the third-party resources that I depend on, like CosmosDB, SendGrid, and Redis. Fifth, if you really thought that your app shouldn't be upgraded as fast as the LTS schedule, you can always skip the updates. Go from .NET 6 to .NET 10. You can do that. It will be a much bigger upgrade when you do, which means you are less likely to do it, but you can do it. And yes, you can deploy those apps to Azure even when the version of .NET is no longer supported. That's what containers are for. That's also what self-contained deployments are for, where you deploy the version of .NET along with your app.

[@johnnyblue4799]

@@IAmTimCorey 1. Unnecessary at all is hard to prove and you know it. Someone might choose to use it and then it becomes necessary for them. The question is this: Does it allow me to do things I could not do before? If not it might not be necessary. Security and performance should not come at the expense of breaking backwards compatibility. Much too often MSoft chooses to rewrite everything w/o a care in the world for the grief they cause. It used to be a more stable ecosystem. There's no balance between the need to innovate and the need for stability. Would you like to be forced to upgrade your car every year, or even every three years, because the car company declares it unsafe and/or obsolete? 2. An overload is not the kind of change I'm complaining about. I did not say all changes are useless. That's not e breaking change, is it? It does not require code changes. 3. As I said, most security patches do not/should not require code changes. Just keep the same interfaces.The upgrades should be easy. Roll up the .net core version and update the nuget packages. There were times when updates didn't create so much grief. And the worst are the changes like that which you mentioned. Likely, limiting the bigint will cause a runtime error, not a compilation error. Like some changes to ef core cause runtime errors. Updating tables with triggers fails at runtime w/o changes to the context, but it builds just fine. If they can throw an exception when there's a trigger on the table, why not recover from it automatically and retry the old, less efficient way automatically? And there are more headaches caused by EF upgrades. And the mess is even bigger with Azure libraries like those for reading from blob storage. Fine you'll say, those issues don't make it to production because of testing, but the real issue is the complexity and the duration of an upgrade. Someone needs to pay for it. 4. Not all upgrades are hard. But some are really complex. And they take time. Time that's better spent doing something new instead of playing cat and mouse with MSoft. Even the Angular has a better migration experience than .net. 5. I don't want to skip versions. I want easy upgrades. They choose fast paced releases, fine, but build good tooling to aid in the upgrade process. If everything could be upgraded in 15 minutes, I guess very few would be complaining. The problem is that they don't want to spend the time and money to do it and instead pass the burden to the customers. There are banking systems that still work on Cobol. How do you attract these people to switch when they see the craziness that happens in modern platforms? There's hardly any stability left in the Microsoft development ecosystem... It feels like walking on quicksands.

[@IAmTimCorey]

I'm not going to dive into everything here. I'll be doing some videos on these topics. However, I'm not sure how much easier Microsoft can make these upgrades. Upgrading .NET versions is literally just changing the project file to say net9.0 instead of net8.0, then rebuilding. Yes, if you were using something that was deprecated or changed, you would need to fix that as well, but those things are really rare. Here's a real-world example - my suggestion site ( suggestions.iamtimcorey.com ) was built with .NET 6. I upgraded it to .NET 7 and then to .NET 8 without any additional changes required. I did take advantage of some new things, but I didn't have to do that. I'll do the upgrade to .NET 9 and I expect no issues. This project uses Blazor Server (yes, the template that doesn't even exist anymore, and with the full Program.cs and Startup.cs files), it talks to MongoDB (in Atlas), Redis, and it is hosted on Azure. No problems with any of that. Upgrade issues are almost always because of third-party integrations. Microsoft tries REALLY hard not to break anything during their upgrades.

[@ieaatclams]

Because everyone else is doing the same things

[@IAmTimCorey]

Because the entire industry is changing all the time. Standing still isn't a great option. That's a good way to get run over by the competition.

[@AliMustafa-xp8ih]

The previous introduction was better

[@IAmTimCorey]

It was longer and we used it for over three years. It was time for a change.

[@johnh6788]

Thank you for explaining this. Understanding the method to the madness helps me to plan around the version cycle and to take a step beyond just shaking my fists at Microsoft.

[@IAmTimCorey]

I am glad it was helpful.