Announcing .NET 7 Release Candidate 1

Jeremy Likness

Angelos Petropoulos

Jon Douglas

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.

.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:

.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:

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:

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:

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:

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:

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.

Filip Navara

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:

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!

14 comments

Comments are closed. Login to edit/delete your existing comments

  • Bartłomiej Karwacki 0

    Hello, what about MSDTC support? I’m positive I saw some windows-only implementation on .NET 7 test branch, but still no official word on that front?
    Related issue (https://github.com/dotnet/runtime/issues/715) is closed. If it’s working and will be a part of .NET 7, I think you definitely should brag about it here 🙂

    • John Tur 0

      The distributed transaction patch should be available in RC1, yes.

  • László Szőke 0

    .NET MAUI for Linux; where or when? Never? Ok, you are the best guys.

    • bugs enjoyer 1

      Use your brain as well as windows if you wanna reach fulfillments. Windows never lets you down, even when PC is shut down. Every kid knows on Earth that windows leads you to your goals. Every task is done if your machine has windows on. You should forget about Linux, because the best is only windows. From now on, you know the truth, you have the wisdom, you see what you should always use. I know your tears are falling down, but it’s OK, I’m also crying. We know the truth, we have the wisdom. We are so grateful, thank you Windows!!! 

      I’m so ready for advertising job.

    • W L 0

      If you really have a very strong need, then you should go with a more mature solution rather than expecting a new framework, can MAUI be put into real production in three years? It will be a great success if it does not become the next UWP….

      Windows Only or Web (or Qt, if you prefer C++ or you need better performance, qt for python is also good choice, we have many packaging solution). These are the ultimate answers, because they are more mature and already have a good community.

      Also, even on Windows, I think these new UI technologies are unnecessary and it would be better to continue to enhance WPF (and Winform?), but unfortunately, that won’t get more people promoted.

  • Jean Tejeda 0

    Will we be able to create and run MAUI projects from .net cli through VSCode on .net 7 final release? or would it always be needed to use Visual Studio?
    Because I’ve a 256GB SSD, so full-on Visual Studio is a no-no.

    • bugs enjoyer 0

      man just upgrade your ssd. Just use aliexpress with low prices, duh…

      • Jean Tejeda 0

        Well… that’s the funny thing, you can’t on a M1 Macbook Pro, thanks to Apple. And 256GB was the only model I could get a hold on to in latin america.

    • Sami Gülen 1
      dotnet workload install maui
      dotnet new maui
      • Jean Tejeda 0

        Nice, it does work, thank you!
        Really weird it isn’t documented yet, but using

        dotnet workload search

        it does appear.

    • Alexey Gritsenko 0

      Now for the VS and various SDKs (android, windows, etc.) even 512GB is not enough. I recently had to buy myself a new 1tb m2 ssd.

  • Mirano Galijasevic 2

    If you could please fix the .Net 6 first, that would be awesome. Blazor is not production ready, and never was, so maybe fixing things in the LTS before all the .Net MEOW-ing framework, which will not work properly before 2027, if even then. You know, we kind of pay for this and use it for business, not for fun.
    Let me help you, just google for: .Net 6 Blazor debugger reduce wasm size variables not showing values…etc. Sorry, don’t use google, Bing search for it.
    Or maybe forget about all that, it is hard to make it work, you can always spin off another garbage functionality like minimal API, which will add nothing to the productivity and create even more confusion and work.

    • Undefined 0

      Yeah, I totally agree with you. We don’t need small changes of API, we just want production ready solution that will work for multiple years.

    • Alexey Gritsenko 0

      Also a little annoyed. Stability is the key to success is my motto. Instead, they began to rivet new releases of dotnet too often.

Feedback usabilla icon