Today we announce .NET 7 Release Candidate 1. This is the first of two release candidates (RC) for .NET 7 that are supported in production.

You can download .NET 7 Release Candidate 1, for Windows, macOS, and Linux.

• Installers and binaries
• Container images
• Linux packages
• Release notes
• Known issues
• GitHub issue tracker

.NET 7 Release Candidate 1 has been tested with Visual Studio 17.4 Preview 2. We recommend you use the preview channel builds if you want to try .NET 7 with Visual Studio family products. If you’re on macOS, we recommend using the latest Visual Studio 2022 for Mac preview.

Don’t forget about .NET Conf 2022. Join us November 8-10, 2022 to celebrate the .NET 7 release!

In this blog, we’ll highlight the core themes of .NET 7 and provide you with resources to dive deeper into the details.

For a more detailed recap of all the features and improvements included in .NET 7 Release Candidate 1, check out the previous .NET 7 Preview blog posts:

• Announcing .NET 7 Preview 1
• Announcing .NET 7 Preview 2
• Announcing .NET 7 Preview 3
• Announcing .NET 7 Preview 4
• Announcing .NET 7 Preview 5
• Announcing .NET 7 Preview 6
• Announcing .NET 7 Preview 7

.NET MAUI

.NET Multi-platform App UI (MAUI) unifies Android, iOS, macOS, and Windows APIs into a single API so you can write one app that runs natively on many platforms. .NET MAUI enables you to deliver the best app experiences designed specifically by each platform (Android, iOS, macOS, Windows, and Tizen) while enabling you to craft consistent brand experience through rich styling and graphics. Out of the box, each platform looks and behaves the way it should without any additional widgets or styling required.

As part of .NET 7, .NET MAUI provides a single project that handles multi-targeting across devices and their platforms. To learn more about the productivity improvements, tooling, and performance enhancements check out these resources:

• Introducing .NET MAUI – One Codebase, Many Platforms
• Productivity comes to .NET MAUI in Visual Studio 2022
• Performance Improvements in .NET MAUI
• .NET Conf Focus on MAUI – That’s a wrap!

Cloud Native

A set of best practices for building your apps for and in the cloud to take advantage of resilience, scalability, efficiency, and velocity.

.NET is a great choice to build cloud native apps. To learn more about cloud native features and improvements in .NET 7, check out these resources:

• Announcing built-in container support for the .NET SDK
• Announcing gRPC JSON transcoding for .NET
• .NET 7 comes to Azure Functions & Visual Studio 2022

ARM64

ARM provides the best of both worlds; a small chip with a giant leap of exceptional performance and unbelievable power efficiency.

.NET helps you build applications to run on ARM devices. For more information on how fast .NET 7 runs on ARM64, check out these resources:

• Arm64 Performance Improvements in .NET 7

Modernization

Being on a modern version of .NET lets you take advantage of lightning fast performance with a plethora of new features improving your developer quality of life.

To make the upgrade experience as seamless as possible, the .NET Upgrade Assistant provides you with a guided step-by-step experience to modernize your .NET applications by analyzing and upgrading your project files, code files, and dependencies.

For more information on how .NET 7 helps you modernize your applications, check out these resources:

• Incremental ASP.NET to ASP.NET Core Migration
• Migrating from ASP.NET to ASP.NET Core in Visual Studio

Performance

.NET is fast. .NET 7 is the fastest .NET yet. Over a thousand performance-impacting improvements went into .NET 7 impacting reflection, On Stack Replacement(OSR), start-up time, Native AOT, loop optimizations and many other areas.

For more information on why .NET 7 is the fastest version yet, check out these resources:

• Performance Improvements in .NET 7
• Regular Expression Improvements in .NET 7

WebSockets over HTTP/2

The WebSocket Protocol over HTTP/2 is based on the RFC 8441. It uses a different approach than web sockets over HTTP/1.1 due to the multiplexing nature of the HTTP/2 connection. It allows to have streams of both protocols (WebSockets and plain HTTP/2) in one connection simultaneously and therefore use the network more efficiently. To manage the connection with several streams of one or both protocols, you have to provide a custom HttpMessageInvoker. In that case, you should use the overlapping options from the invoker instead of ClientWebSocketOptions.

In case the server does not support WebSockets over HTTP/2 or does not support HTTP/2 protocol at all, you can allow downgrade to WebSockets over HTTP/1.1 by setting up the respective policy in the ClientWebSocketOptions. By default, ClientWebSocket uses HTTP/1.1 version and RequestVersionOrLower policy, therefore WebSockets over HTTP/2 won’t be used by default.

Usage

var handler = new SocketsHttpHandler();

ClientWebSocket ws = new();
ws.Options.HttpVersion = HttpVersion.Version20;
// to disable downgrade
ws.Options.HttpVersionPolicy = HttpVersionPolicy.RequestVersionOrHigher;
// by default downgrade is enabled:
// ws.Options.HttpVersionPolicy = HttpVersionPolicy.RequestVersionOrLower;

ws.ConnectAsync(uri, new HttpMessageInvoker(handler), cancellationToken);

References

See https://github.com/dotnet/runtime/issues/69669

Support using ICU library by default on Windows Server 2019

.NET started to use the ICU library for globalization support in .NET 5.0 and up. Windows Server 2019 was lacking ICU support. Services and apps running on Windows Server 2019 which want to use ICU, needed to deploy ICU and enable some configuration to use it as described in the doc. In .NET 7.0, the ICU will be supported by default on Windows Server 2019.

References

See https://github.com/dotnet/runtime/issues/62329, https://github.com/dotnet/runtime/pull/72656, and https://github.com/dotnet/docs/issues/30319

Improve the calculation precision of Add methods in DateTime and DateTimeOffset

Improved the calculation precision of the DateTime and DateTimeOffset methods AddDays, AddHours, AddMinutes, AddSeconds, AddMilliseconds, and AddMicroseconds to produce a better result.

References

https://github.com/dotnet/runtime/issues/66815 and https://github.com/dotnet/runtime/pull/73198

System.Diagnostics.TraceSource can now be initialized from the app.config file

Primarily to make it easier to migrate from .NET Framework, support was added for initializing a TraceSource and related types including Switch and TraceListener from the application’s config file.

Note that an explicit call must be made to enable this functionality through System.Diagnostics.TraceConfiguration.Register().

Usage

A package reference to System.Configuration.ConfigurationManager is required.

An example C# console app named ConsoleApp1 would use a config file named ConsoleApp1.dll.config and placed in the application’s bin folder.

Sample of a config file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.diagnostics>
    <sources>
      <source name ="MyTraceSource" switchName="MainToggle" switchType="System.Diagnostics.SourceSwitch" />
    </sources>
    <switches>
      <add name = "MainToggle" value="Error" /> <!-- Set to Off to disable logging -->
    </switches>
  </system.diagnostics>
</configuration>

and C#

using System.Diagnostics;

namespace ConsoleApp1
{
    internal class Program
    {
        static void Main(string[] args)
        {
            TraceConfiguration.Register(); // Required to enable reading from the config file.

            // Get the configured TraceSource
            TraceSource ts = new TraceSource("MyTraceSource", SourceLevels.Error);

            // Add a listener
            TextWriterTraceListener listener = new("TextWriterOutput.log", "myListener");
            ts.Listeners.Add(listener);

            // The "MainToggle" SourceSwitch in the config file is set to Error, so this will log:
            ts.TraceEvent(TraceEventType.Error, 101, "Error message.");
            listener.Flush();
        }
    }
}

References

See https://github.com/dotnet/runtime/issues/23937 and https://github.com/dotnet/runtime/pull/73087

Support XmlSchema Import/Export with DataContractSerializer

.NET 7.0-RC1 brings the return of XmlSchema importing and exporting from .NET Framework 4.8 in the DataContractSerializer space. The API is as similar to the 4.8 API as possible to enable easy porting of code from .NET Framework. The export functionality is a built-in feature along with DataContractSerializer in the 7.0 SDK. The import functionality is available in an add-on package named System.Runtime.Serialization.Schema. (This package is not part of the 7.0 SDK as it depends on System.CodeDom, which is also shipped as a separate package.)

References

See https://github.com/dotnet/runtime/issues/72243, and the 4.8 Export and Import API docs for the Framework feature that preceded this work.

Detecting HTTP/2 and HTTP/3 protocol errors

When using HttpClient with the default SocketsHttpHandler, it’s possible now to detect HTTP/2 and HTTP/3 protocol error codes (not to be confused with HTTP status codes!). This feature is useful for advanced applications like gRPC.

Usage

When calling HttpClient methods

using var client = new HttpClient();

try
{
    var response = await client.GetStringAsync("https://myservice");
}
catch (HttpRequestException ex) when (ex.InnerException is HttpProtocolException protocolException)
{
    Console.WriteLine("HTTP2/3 protocol error code: " + protocolException.ErrorCode);
}

When calling response stream methods

using var client = new HttpClient();
using var response = awaitclient.GetAsync("https://myservice", HttpCompletionOption.ResponseHeadersRead);
using var responseStream = await response.Content.ReadAsStreamAsync();
using var memoryStream = new MemoryStream();

try
{
    await responseStream.CopyToAsync(memoryStream);
}
catch (HttpProtocolException protocolException)
{
    Console.WriteLine("HTTP2/3 protocol error code: " + protocolException.ErrorCode);
}

References

See dotnet/runtime#70684

Contributor spotlight: Filip Navara

A huge “Thank you” goes out to all our community members. We deeply appreciate your thoughtful contributions. We asked contributor @filipnavara to share his thoughts.

In Filip’s own words:

I started playing with computers as a kid. While visiting my grandpa, I often saw him doing his work in BASIC. He was writing factory automation software, and I inherited my love for all things technical from him. DOS was the standard system back then, and Borland dominated the programming tools. I wanted to understand how programming works and to learn it. Stubbornly I refused all his advice and had to learn everything myself by trial and error. It was foolish, but seeing the little programs come to life was fun.

Gradually I started programming in different languages, exploring the internet and then the world of open source. I mostly enjoyed coding on low-level software such as compilers, operating systems, or system emulators. In my spare time during high school, I contributed to projects like Wine, ReactOS, QEMU, Binutils, and the MinGW compiler tool set.

When the first version of .NET Framework came out, I was immediately intrigued. It promised the simplicity of Delphi that I was familiar with, and the C# language was genuinely fun to learn. The timing was perfect since I joined my friends to start a small project to develop an email client application, and we all agreed to build it in .NET. That application, eM Client, kept me occupied throughout my university studies. It is still my current project to this day; even though the team has grown, my responsibilities have shifted, and we’ve got a lot of very talented programmers to relieve me of my duties.

Open sourcing of .NET was a big blessing for us and made many things easier. Nowadays, I can focus more on side projects, and contributing to .NET is a natural choice. It allows me to use my knowledge to the full extent, from the low-level details of hardware, and operating system internals, to the high-level frameworks that our email application builds on.

The open code allowed me to drive a project to port WinForms framework to macOS (based on Mono code but using Cocoa native controls in many places). I started contributing more when .NET 5 unification plan started taking place. It was always a pain point for us that different platforms like Xamarin.Mac and Mono lagged in the supported features behind the .NET we used on Windows. Initially, I started to fill the gaps in Mono base class library, which was already sharing some code with .NET Core. I realized that this game of catching up might not be the best solution, so I started exploring other options like running Xamarin.Mac on CoreCLR. It happened to take place just days before the first MonoVM (Mono runtime in .NET 5+) commits were written. Once I realized what was happening, I jumped on board that plan. All that work happened hidden in the open on GitHub, with an official announcement coming a few months later at the Build conference. It was thrilling to see the progress, to build my own Xamarin runtime build that ran on this early unified MonoVM runtime, that showed the first UI. Eventually, it started even our email client application. It was indeed a game changer for us. With the old .NET Framework, we could not use the new features when they were released. It took years before the deployment of new releases caught up. Now I was in the opposite situation, running bleeding edge bits before everyone else!

This work on the runtime unification has now successfully concluded, and we released our application with the latest .NET 6 bits to our customers. However, many places in .NET can still be improved, and I enjoy working with the people on the .NET team. I try to drive at least one minor feature for each release. For .NET 6, I focused on getting the iOS cryptography stack working. For .NET 7, I took a stab at a niche API for handling Negotiate/Kerberos/NTLM authentication with the great help of the networking team. While it’s not a very attractive or visible feature, it was long-term technical debt. The code was lacking in the unit and functional tests; ASP.NET accessed the internals through reflection, which is not NativeAOT friendly; and most importantly, library authors had to use complicated ways to get around the lack of simple public API.

I sincerely hope to contribute more in the future, and I enjoy seeing other contributors finding their areas of interest and making the whole platform better for everyone!

Support

.NET 7 is a Short Term Support (STS) release, meaning it will receive free support and patches for 18 months from the release date. It’s important to note that the quality of all releases is the same. The only difference is the length of support. For more about .NET support policies, see the .NET and .NET Core official support policy.

We recently changed the “Current” name to “Short Term Support (STS)”. We’re in the process of rolling out that change.

Roadmaps

Releases of .NET include products, libraries, runtime, and tooling, and represent a collaboration across multiple teams inside and outside Microsoft. You can learn more about these areas by reading the product roadmaps:

• ASP.NET Core 7 and Blazor Roadmap
• EF 7 Roadmap
• ML.NET
• .NET MAUI
• WinForms
• WPF
• NuGet
• Roslyn
• Runtime

Closing

We appreciate and thank you for your all your support and contributions to .NET. Please give .NET 7 Release Candidate 1 a try and tell us what you think!