.NET Versions and Why Upgrades Are Routine

This may be boring, and you may know all of it already. It is a short review, and it matters. Before we create the real project, you should know how fast .NET moves, because that decides how we organize the project.

There is no code to run in this lesson.

Two families, and a name problem

There are two families of .NET:

.NET Framework is the original, from 2002. It still runs many old business systems. Microsoft keeps it safe, but it gets no new features.

.NET Core was a rewrite, started in 2016, that works everywhere and is much faster. It was named ".NET Core" up to version 3.1. From version 5, Microsoft dropped the word "Core", so the name is now just .NET. The next version after 3.1 jumped to 5 on purpose, to avoid a clash with .NET Framework 4.x.

So when someone says "dotnet core" today, they usually mean modern .NET. This course uses .NET 10. Everything new in this course is the modern kind.

A new version every year

Modern .NET has a fixed rhythm: a new version every November.

Each version is one of two kinds:

• LTS (long-term support): an even number, such as 8 or 10. Microsoft supports it for 3 years.
• STS (standard-term support): an odd number, such as 9. Microsoft supports it for 2 years.

Supported means Microsoft keeps fixing security problems in it. When support ends, a problem found tomorrow will not be fixed, so you must move to a newer version.

Look at the picture. A new version is released every year, and the oldest ones keep ending. At any moment you are never more than a few years from the end of support.

Microsoft publishes the exact dates on its .NET support policy page. We show only the rule here, because dates change and a copy would go out of date.

Which one should you pick?

• For real work, most teams pick the newest LTS. It gives the longest time before the next forced upgrade.
• An STS version is fine for trying new things, but you will have to upgrade sooner.
• This course uses .NET 10, which is LTS.

Do not think of the number as something you pick once. Whatever you pick, you will have to move to a newer one later.

What an upgrade costs

Every .NET project says which version it targets. It is one line in the project file, TargetFramework:

<TargetFramework>net8.0</TargetFramework>

To upgrade, you change that line to net10.0. One line is easy. But a real solution has many projects (lesson 01), and each one has its own copy of that line:

The packages (ready-made libraries, also from lesson 01) have the same problem. Each project writes down its own package versions, so they can drift apart, and the upgrade has to touch each of them.

Now picture a company with 40 projects, upgrading every year or two. Editing every file by hand each time is slow, boring and easy to get wrong. Missing one project can break the build, or leave one part of the system on an old version that is no longer supported.

The fix, and what is next

The fix is simple to say: write each version down once, in one shared place, and let every project read it from there. Then an upgrade is a change in one file, not in forty.

This is exactly what Directory.Build.props and Directory.Packages.props do. You met them in lesson 01 as an idea. In the next lesson we create the real bookshop solution and set them up on day one, so that upgrades stay cheap for the life of the project.

Recap

• There are two families: .NET Framework (old, Windows only, no new features) and modern .NET (cross-platform, open source, new features every year).
• ".NET Core" was the name up to 3.1. Since version 5 it is just .NET.
• A new version comes every November. Even numbers are LTS (3 years of support) and odd numbers are STS (2 years).
• Most teams choose the newest LTS. This course uses .NET 10.
• Upgrades come often, so a project should keep its version numbers in one shared place, not in every project file.

Questions to think about

The answers are not given here on purpose, so check yourself against the lesson.

1. Which gets support for longer, LTS or STS? Which would you pick for a project that must run for many years, and why?
2. A colleague says "we are moving from dotnet core to .NET 10". Are those two different things? Explain in one sentence.
3. A company has 6 projects on an old version, and each project file has its own copy of the version number. Why does a yearly release make this a problem?
4. How could you change a version number once and have all 6 projects pick it up? (The next lesson answers this.)

Next lesson: we create the solution and the API project, and set up the shared settings once.