What's new in .NET 7 RC 1

[leecow]

trafficstars

What's new in .NET 7 RC 1

This issue is for teams to highlight work for the community that will release .NET 7 RC 1

To add content, use a new conversation entry. The entry should include the team name and feature title as the first line shown in the template below.

## Team Name: Feature title

[link to the tracking issue or epic item for the work]

Tell the story of the feature and anything the community should pay particular attention 
to be successful using the feature.

Preview 1: https://github.com/dotnet/core/issues/7106 Preview 2: https://github.com/dotnet/core/issues/7107 Preview 3: https://github.com/dotnet/core/issues/7108 Preview 4: https://github.com/dotnet/core/issues/7378 Preview 5: https://github.com/dotnet/core/issues/7441 Preview 6: https://github.com/dotnet/core/issues/7454 Preview 7: https://github.com/dotnet/core/issues/7455 RC 1: https://github.com/dotnet/core/issues/7716 RC 2: https://github.com/dotnet/core/issues/7717

[karelz]

FYI: There is a feature we didn't get time to document for P7 (due to vacation, resourcing, etc.) - sorry for that! -- Perhaps we can include it in RC1 blog post? Or maybe the P7 response will be turned into P7 blog post update? @leecow can you please advise? Thanks!

https://github.com/dotnet/core/issues/7455#issuecomment-1225655505

[teo-tsirpanis]

@karelz we can add it to the RC1 blog post, it's not the first time that happens. If we updated the P7 post nobody would see it. 😅

[greenEkatherine]

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

[danmoseley]

@ericstj @jeffhandley anything from your teams?

[tarekgh]

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

[tarekgh]

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

[steveharter]

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

[StephenMolloy]

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.

[teo-tsirpanis]

(copying https://github.com/dotnet/core/issues/7455#issuecomment-1225655505 here to make sure you don't miss it)

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

[karelz]

I didn't see list of above features in RC1 blog post https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-rc-1/ -- did I miss it, or was it intentional? @JeremyLikness @leecow

[danmoseley]

[RegexGenerator] attribute was renamed to [GeneratedRegex]. https://devblogs.microsoft.com/dotnet/regular-expression-improvements-in-dotnet-7/ is edited to note that.

[danmoseley]

@JonDouglas the above info was missed from the RC1 post. Could we please include in RC2? Cc @leecow

[JonDouglas]

@danmoseley We missed this issue after looking for it last week. Which is also why the blog PR wasn't linked to this issue.

Since it's only been a week, perhaps we can just backfill this content to RC1? (Still healthy viewership).

I tagged us for the RC2 issue so we have visibility.

Thanks for the heads up!

[karelz]

@JonDouglas if we add it into RC1 blog post 1 week late (which is IMO fine), perhaps we can then mention the fact (of late update) in RC2 blog post and catch 1st-week set of viewers?

[JonDouglas]

@karelz Sure thing. We will also include it in the RTM blog more expanded.

[leecow]

.NET 7 GA is available. Closing these pre-release issues.