Understanding .NET

“Those who cannot remember the past are condemned to repeat it.”

– George Santayana

.NET, .NET Core, .NET Framework, .NET Standard, and Xamarin are related and overlapping platforms for developers used to build applications and services.

If you are not familiar with the history of .NET, then I will introduce you to each of these .NET concepts at the following link:

https://github.com/markjprice/cs14net10/blob/main/docs/ch01-dotnet-history.md.

As time moves on, more and more readers already know the history of .NET, so it would be a waste of space in the book to continue to include it. But if you are new to it, then make sure you read all the extras that I provide online, like the preceding one.

Understanding .NET support

.NET versions are either Long-Term Support (LTS), Standard-Term Support (STS) (formerly known as Current), or Preview, as described in the following list:

• LTS releases are supported by Microsoft for 3 years after General Availability (GA), or 1 year after the next LTS release ships, whichever is longer.
• STS releases are supported by Microsoft for 2 years after GA, or 1 year after the next STS or LTS release ships, whichever is longer.
• Preview releases are for public testing. These should only be used by adventurous programmers who want to live on the bleeding edge, or programming book authors who need to have early access to new language features, libraries, and app and service platforms. Preview releases are not usually supported by Microsoft, but some preview or Release Candidate (RC) releases may be declared Go Live, meaning they are supported by Microsoft in production. But you must migrate to the final release as soon as it is available.

STS and LTS releases receive critical patches throughout their lifetime for security and reliability.

To better understand your choices of STS and LTS releases, it is helpful to see their support durations visualized, with 3-year-long black bars for LTS releases, and 2-year-long gray bars for STS releases, as shown in Figure 1.3:

Figure 1.3: Support durations for recent and planned STS and LTS releases

During the lifetime of .NET 10, .NET 8 and .NET 9 will still be supported (for a while), and .NET 11 and .NET 12 will be released. I have tried to be cognizant that you might choose to use future versions like .NET 11 or .NET 12 with this book; however, obviously, the book cannot cover those new features, since I don’t know what they will be!

If you have existing .NET 8 and .NET 9 projects, then you should start work on migrating them to .NET 10 as soon as possible.

If you need LTS from Microsoft, then set your new .NET projects to target .NET 10 today and then migrate to .NET 12 after it is released in November 2027. This is because .NET 11 will be an STS release, and therefore, it will lose support in November 2028, on the same day that .NET 10 reaches its end-of-life. As soon as .NET 12 is released, start upgrading your .NET 10 projects to it. You will have a year to do so before .NET 10 and .NET 11 reach their end-of-life date.

Understanding .NET support phases

The lifetime of a version of .NET passes through several phases, during which they have varying levels of support, as described in the following list and as shown in Figure 1.4:

• Preview: These are not supported at all. .NET 10 Preview 1 to Preview 7 were in this support phase from February 2025 to August 2025.
• Go Live: These are supported until GA, and then they become immediately unsupported. You must upgrade to the final release version as soon as it is available. .NET 10 Release Candidate 1 and Release Candidate 2 were in this support phase in September and October 2025, respectively.
• Active: .NET 10 will be in this support phase from November 2025 to May 2028. Monthly releases include bug fixes and security fixes. You must update to any patch version release every month to have support.
• Maintenance: Supported only with security fixes for the last six months of its lifetime. .NET 10 will be in this support phase from May 2028 to November 2028. In May 2026, .NET 8 and .NET 9 enter their maintenance phase. If you have existing projects that target .NET 8 or .NET 9, then you should migrate those projects to .NET 10 because it could take up to six months to do so for a large project.
• EOL: Not supported. .NET 10 will reach its EOL in November 2028.

Figure 1.4: .NET 10 support phases from preview to maintenance

Understanding end of life

End of support or end of life (EOL) means the date after which bug fixes, security updates, or technical assistance are no longer available from Microsoft.

At the time of publishing in November 2025, all versions of modern .NET have reached their EOL, except those shown in the following list:

• .NET 8 is in its active phase. It will enter its maintenance phase in May 2026, and it will reach its EOL in November 2026.
• .NET 9 is in its active phase. It will enter its maintenance phase in May 2026, and it will reach EOL in November 2026.
• .NET 10 will be in its active phase until May 2028, then it will be in its maintenance phase until it reaches EOL in November 2028.
• .NET 11 will be in its preview phase from February 2026 to early November 2026. It will be active from November 2026 to May 2028, and it will reach EOL in November 2028.
• .NET 12 will be available in preview from February 2027, then be active from November 2027, and it will reach EOL in November 2030.

When .NET 8 and .NET 9 reach their end of support in November 2026, you can expect the following:

• Projects that use .NET 8 or .NET 9 will continue to run
• No new security updates will be issued for .NET 8 or .NET 9, and therefore, continuing to use an unsupported version will increasingly expose you to security vulnerabilities
• You might not be able to access technical support for any .NET 8 or .NET 9 applications that you continue to use
• You will get NETSDK1138 build warnings when targeting .NET 8 or .NET 9 from recent SDKs like the .NET 10 SDK
• You will get warnings in Visual Studio when targeting .NET 8 or .NET 9

Understanding .NET Runtime and .NET SDK versions

If you have not built a standalone app, then the .NET Runtime is the minimum you need to install so that an operating system can run a .NET application. The .NET SDK includes the .NET Runtime, as well as the compilers and other tools needed to build .NET code and apps.

.NET Runtime versioning follows semantic versioning, that is, a major increment indicates breaking changes, minor increments indicate new features, and patch increments indicate bug fixes.

.NET SDK versioning does not follow semantic versioning. The major and minor version numbers are tied to the runtime version they are matched with. The third number follows a convention that indicates the minor and patch versions of the SDK. The third number starts at 100 for the initial version (equivalent to 0.0 for the minor and patch numbers). The first digit increments with minor increments, and the other two digits increment with patch increments.

You can see an example of this in Table 1.3:

Table 1.3: Examples of changes and versions for a .NET Runtime and .NET SDK

Listing and removing versions of .NET

All future versions of the .NET 10 runtime are compatible with its major version. For example, if a project targets net10.0, then you can upgrade the .NET Runtime to future versions like 10.0.1, 10.0.2, and so on. In fact, you must upgrade the .NET Runtime every month to maintain support.

All future versions of the .NET SDK maintain the ability to build projects that target previous versions of the runtime. For example, if a project targets net10.0 and you initially build it using .NET SDK 10.0.100, then you can upgrade the .NET SDK to future bug-fix versions, like 10.0.101, or a major version, like 11.0.100, and that SDK can still build the project for the older targeted version. This means that you can safely remove all older versions of any .NET SDKs, like 8.0.100, 9.0.100, or 10.0.100, after you’ve installed a .NET SDK 11 or later. You will still be able to build all your old projects that target those older versions.

You can see which SDKs and runtimes are currently installed using the following commands:

dotnet --list-sdks
dotnet --list-runtimes
dotnet --info

On Windows, use the Apps & features section to remove .NET SDKs.

On Linux, there is no single mechanism, but you can learn more at the following link:

https://learn.microsoft.com/en-us/dotnet/core/install/remove-runtime-sdk-versions?pivots=os-linux.

Understanding how .NET and C# are related

.NET and C# are closely related technologies. C# is a programming language that compiles to Common Intermediate Language (CIL), aka IL code. IL code can then be loaded by the Common Language Runtime (CLR) that is part of the .NET Runtime and Just In Time (JIT) compiled to native CPU instructions, aka machine code, that are executed by your computer.

There are other languages, like Visual Basic .NET and F#, that can also be compiled to IL code, so they are alternatives to C# that can create .NET assemblies (libraries and executables), as shown in Figure 1.5:

Figure 1.5: How C# and other languages are related to .NET

You can build .NET projects without C#, but C# can only build projects for .NET. In theory, since C# is an open standard, someone could create a C# compiler that builds projects for other platforms, but in practice, no one has done this.

If you are a C# programmer, then you always build .NET projects. If you are a .NET programmer, then you most likely use C#, or you could use F# or Visual Basic. Despite Microsoft’s support for multiple languages within the .NET ecosystem, including C#, F#, and Visual Basic, C# has maintained a dominant position. According to JetBrains’ 2023 Developer Ecosystem survey, 99% of .NET developers use C#, while 7% use Visual Basic, and 3% use F#. While F# and Visual Basic have their dedicated user bases and specific use cases, C# remains the overwhelmingly preferred language among .NET developers.

Understanding intermediate language

.NET has a two-step compilation process, as shown in Figure 1.5. In the first step, the C# compiler (named Roslyn) used by the dotnet CLI tool converts your C# source code into intermediate language (IL) code and stores the IL in an assembly (a DLL or EXE file). IL code statements are like assembly language instructions, which are executed by .NET’s virtual machine, known as CoreCLR, the newer name for the CLR in modern .NET. The legacy .NET Framework has a CLR that is Windows-only, and modern .NET has one for each OS, like Windows, macOS, and Linux. These days, they are all commonly referred to as CLRs.

In the second step, usually at runtime, CoreCLR loads the IL code from the assembly, the JIT compiler compiles it into native CPU instructions, and then it is executed by the CPU on your machine.

The benefit of this two-step compilation process (C# to IL, then IL to native CPU instructions) is that Microsoft can create CLRs for Linux and macOS, as well as for Windows. The same IL code runs everywhere because of the second compilation step, which generates code for the native operating system and CPU instruction set.

Regardless of which language the source code is written in (for example, C#, Visual Basic, or F#), all .NET applications use IL code for their instructions stored in an assembly. Microsoft and others provide disassembler tools that can open an assembly and reveal this IL code, such as the ILSpy .NET Decompiler extension. You will learn more about this in Chapter 7, Packaging and Distributing .NET Types, in an online section found at the following link: https://github.com/markjprice/cs14net10/blob/main/docs/ch07-decompiling.md.

So, the compilation process typically involves translating source code into IL, which is then compiled into machine code at runtime by the CLR using JIT compilation. Ahead-of-Time (AOT) compilation is an alternative to this approach, and you will learn about it in Chapter 7, Packaging and Distributing .NET Types.

Comparing legacy and modern .NET technologies

We can summarize and compare the current .NET technologies, as shown in Table 1.4:

Table 1.4: Comparison of .NET technologies

Now that we’ve covered a lot of theory, let’s move on to some practical tasks, like building your first project and learning how to manage multiple projects in a solution. Visual Studio, Rider, and even VS Code (with the C# Dev Kit extension installed) all have a concept called a solution that allows you to open and manage multiple projects simultaneously. We will use a solution to manage the two projects that you will create in this chapter.