It’s nice to have a predictable release cycle for .NET. Back in the old days of the .NET Framework, releases were few and far between, and changes were often minimal. That wasn’t particularly bad, but having the development platform tied to the Windows release cycle sometimes meant waiting years for promised features.
With the move to an open source platform, initially with the parallel development of .NET Core and the .NET Standard base classes, and finally with the merged .NET, things have changed. We now get an annual .NET release, tied to the .NET Conf event in November, with 18 months of support for STS (Standard Term Support) releases and three years of support for LTS (Long Term Support) releases. Odd-numbered versions of .NET are STS, and even-numbered versions are LTS.
The next .NET LTS release
The next .NET release, due in November 2023, will be .NET 8. As an LTS release, .NET 8 will become many organizations’ default version of .NET for at least the next two years. .NET 7 brought a lot of changes, and this new release builds on top of them, while adding more new features. It’s worth spending some time with the current preview releases to see how existing code ports to the new version, and to determine what changes you might need to make.
As the .NET platform continues to evolve, Microsoft is making plenty of changes to the underlying compiler to support new language capabilities and features, surfacing primarily in a new release of C#.
.NET garbage collector improvements
One new API is especially interesting, at least if you’re building .NET code for cloud-native applications running on platforms like Kubernetes. You can now change the memory limit for an application on the fly, using the .NET garbage collector. That makes it possible to scale app resource consumption up and down as demand dictates. When demand is low, applications can scale down to a minimum, ensuring you don’t pay for resources you don’t need.
A JSON upgrade
How .NET manages JSON serialization and deserialization has also been improved, with the addition of support for new numeric types including the new half struct. This implements an IEEE float16 type, so it should be useful when delivering data to machine learning models. Half-precision numbers align more closely with the floating-point hardware used in hardware accelerators and NPUs, as well as the new numeric instructions recently added to Intel processors, and make it easier to use general purpose GPU compute tools. Normalizing numeric values to half-precision in serialization should allow tools like this to work more efficiently.
The .NET team has done a lot of work on its JSON tooling, beyond adding support for new types. New API methods make it easier to write specific nodes to a JSON document, while other features improve how .NET manages the content of your JSON. These updates help to ensure the integrity of JSON documents, and to solidify .NET’s role in cloud-native development, as JSON now represents the most common payload when calling REST APIs.
New .NET methods for randomness
Another key area for updates is support for new tools that provide randomness. This isn’t the familiar random number generator, but a more direct way of using randomness as a selector in your code. Instead of having to run calculations, you can randomly pick items from an input set and place them in an output array, ready for use. The tooling gives you the option to randomly shuffle items in a set of data. Like many other new .NET features, this can be useful when working with machine learning. For example, it will make it easier to shuffle your data so that training and test data are different each time you build a model, reducing the risk of bias in your data.
Closely related to this is a set of new cryptography tooling, adding support for SHA-3 as an alternative to SHA-2. Improved hashing is always important, as it helps you prepare your code for upcoming cryptographic standards. Other improved security features mean that web proxies can now be addressed over HTTPS, improving the privacy of connections between your apps and the rest of the internet.
.NET and next-gen silicon
Some new features are tied to silicon advances, so they won’t be available on all platforms. These include vector acceleration features built on top of the Intel AVX-512 instruction set. .NET 8 provides a flag to test for AVX support, so you can write error handling code to avoid calling the new vector instructions on older harder, or on AMD or Arm processors. If you have AVX-512 hardware .NET’s updated compiler gives you improved performance on older vector and array instructions, as they can still use the newer hardware features.
Some of the updates appear less straightforward, like the new time abstraction feature. This lets you create a local time provider that can be set up to operate in different time zones outside your current local time or UTC. It’s a way of creating mock times for tests, so you can programmatically control the time zone an application is running in, looking for time-related and timer-related bugs.
Breaking changes in .NET 8
The biggest risks to your existing code come from .NET 8’s breaking changes. Most of these won’t be a surprise, as they’re the result of planned deprecations or changes to support infrastructure. There shouldn’t be too many issues here, as workarounds are available wherever code changes are necessary.
As .NET is no longer a Windows-only technology, one area that ushers in a number of changes is the bundled container images. These changes are mainly due to upgraded versions of the host Linux distributions (for example a version bump in the Debian host), as well as changes that make the images smaller and easier to use. Some of the biggest changes are in the Alpine images, as Alpine no longer contains support for Kerberos and has changed where certificates are stored. 3MB may not seem to be a big reduction in container image size, but when you consider how many images are deployed in the course of a Kubernetes application lifecycle, each 3MB adds up to a considerable saving in bandwidth.
Other changes come from an improved understanding of .NET’s dependencies on shared libraries. Where they’re not required, they’re no longer included. That won’t affect your .NET code, but it may affect other code running in the same container. It’s a best practice to keep functionality isolated, as it reduces security risks, so if you’re using a .NET container to host other code it’s a good idea to rearchitect your application to ensure that code is partitioned correctly.
Microsoft provides a regularly updated list of breaking changes in its .NET 8 preview documentation, indicating in which preview the change occurred. Most were in the first preview, with only a handful added in the latest release. Many changes are behavioral. So while features may have been removed or changed, you should be able to switch to newer ways of working or to alternatives.
Watch out for Windows Forms
One important area to monitor is .NET 8’s Windows Forms implementation. Microsoft has changed how Windows Forms delivers pixel scaling, so you will need to test UIs before pushing new builds to users. Form code is unlikely to fail but may not display correctly, providing a poor user experience. Much of this is to support high DPI screens, ensuring that forms behave correctly when displays have been scaled.
There’s more to .NET 8 than this quick overview. Some new features make it easier to build pre-compiled applications, while others improve performance on Apple’s silicon. Putting it all together, .NET 8 feels like a big update for a LTS release. What you get here will be more than enough to keep your code competitive and secure for the next three years—which is what you want from a platform like .NET.