The .NET Stacks #55: 🆕 Ready or not, here comes .NET 6 Preview 5

Welcome to another busy week! Here's what we have in store this Monday morning:

One big thing: .NET 6 Preview 5 has arrived
The little things: Visual Studio 2022 Preview 1 has arrived, dropping support for older frameworks, Markdown tables extension
Last week in the .NET world

One big thing: .NET 6 Preview 5 has arrived

Even though it still seems that we're still recovering from Preview 4 announced around Build, it's about that time: .NET 6 Preview 5 arrived last Thursday. While Preview 4 brought a lot of developer productivity and experience features like Minimal APIs and Blazor WebAssembly AOT, Preview 5 is a jam-packed release with a lot of work going towards unification in .NET 6.

A big part of that is SDK workloads—announced in Preview 4— a new .NET SDK feature that enables the .NET team to add support for new application types without increasing the size of the SDK. For example, you may want to include MAUI or Blazor WebAssembly application types as you need them. You can view SDK workloads as a package manager for the .NET SDK—the emphasis on the SDK, as Microsoft's vision of one SDK is coming together.

On top of that, Preview 5 brings NuGet package validation, a lot more Roslyn analyzers, improvements to the Microsoft.Extensions APIs, a new JSON source generator, WebSocket compression, OpenTelemetry support, and much more. What about ASP.NET Core? Hot Reload is enabled by default, improvements to Blazor WebAssembly download size with runtime relinking, faster gets and sets for HTTP headers, and more.

With EF Core, Preview 5 brings the first iteration of compiled models. Much like Blazor WebAssembly ahead-of-time (AOT) compilation, the compiled models functionality addresses increasing your startup time. As Jeremy Likness notes: "If startup time for your application is important and your EF Core model contains hundreds or thousands of entities, properties, and relationships, this is one release you don’t want to ignore."

The EF team is reporting 10_x_ performance gains using compiled models. How does this work? When EF creates a context, it creates and compiles delegates to set the table properties. This gives you the ability to query properties right away. Using lazy initialization, EF Core only is accessed when needed. You'll want to check out the blog post for an in-depth discussion of all that's involved. While a fast startup time won't get any complaints, keep in mind that global query filters, lazy loading proxies, change tracking proxies, and IModelCacheKeyFactory implementations aren't supported yet.

If mobile/desktop development is your jam, you'll also want to check out MAUI updates for Preview 5.

The little things: Visual Studio 2022 Preview 1 is here, dropping support for older frameworks, Markdown tables extension

After much fanfare about 64-bit support, Visual Studio 2022 Preview 1 is now here and available for you to try out. By all accounts, it seems to be smooth and snappy—you know, as it should be—and can be installed with earlier versions of Visual Studio. You can check out the Visual Studio 2022 roadmap to see what's coming next.

The 64 bits are getting most of the buzz, but you also may have missed support for IntelliCode completions. These updates complete code for you, sometimes even whole lines of code. Based on your context, it'll predict the next part of code to write, and gives you the option to Tab to accept the changes. Mark Wilson-Thomas mentions this is done by combining a "rich knowledge of your coding context" and also a transformer model that is trained on around half a million public open-source GitHub repositories.

Here's a quick example of me testing it out:

In another example, I wrote a function to print out the first name and last name—it suggested I concatenated the strings together. (I would have preferred string interpolation, but I digress.) Then, as I did a WriteLine call, it suggested I use the method I just wrote.

The .NET team is embarking on an effort to drop older framework versions. While dropping frameworks can be a breaking change, building for every framework version increases complexity and size. The team worked around this by harvesting—building for current frameworks but downloading a package's earlier version and harvest binaries for earlier frameworks. This allows you to update without the worry of losing a framework version, but you won't get any fixes or features from these binaries.

Starting with .NET 6 Preview 5, the .NET team will no longer harvest to ensure support for all assets. This means they are dropping support for frameworks older than .NET Framework 4.6.1, .NET Core 3.1, and .NET Standard 2.0.

As Richard Lander writes:

If you’re currently referencing an impacted package from an earlier framework, you’ll no longer be able to update the referenced package to a later version. Your choice is to either retarget your project to a later framework version or not updating the referenced package (which is generally not a huge take back because you’re already consuming a frozen binary anyways).

Here's something I learned this week: there's a Markdown Tables extension in Visual Studio Code. Who do I talk to about refunding all my time spent tweaking Markdown tables?