Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What's new in .NET 7 RC 1 #7716

Closed
leecow opened this issue Aug 17, 2022 · 16 comments
Closed

What's new in .NET 7 RC 1 #7716

leecow opened this issue Aug 17, 2022 · 16 comments
Assignees

Comments

@leecow
Copy link
Member

leecow commented Aug 17, 2022

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: #7106
Preview 2: #7107
Preview 3: #7108
Preview 4: #7378
Preview 5: #7441
Preview 6: #7454
Preview 7: #7455
RC 1: #7716
RC 2: #7717

@karelz
Copy link
Member

karelz commented Aug 24, 2022

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!

#7455 (comment)

@teo-tsirpanis
Copy link
Contributor

@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
Copy link

greenEkatherine commented Aug 25, 2022

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 dotnet/runtime#69669

@danmoseley
Copy link
Member

@ericstj @jeffhandley anything from your teams?

@tarekgh
Copy link
Member

tarekgh commented Aug 30, 2022

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 dotnet/runtime#62329, dotnet/runtime#72656, and dotnet/docs#30319

@tarekgh
Copy link
Member

tarekgh commented Aug 30, 2022

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

dotnet/runtime#66815 and dotnet/runtime#73198

@steveharter
Copy link
Member

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 dotnet/runtime#23937 and dotnet/runtime#73087

@StephenMolloy
Copy link
Member

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 dotnet/runtime#72243, and the 4.8 Export and Import API docs for the Framework feature that preceded this work.

@teo-tsirpanis
Copy link
Contributor

(copying #7455 (comment) 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
Copy link
Member

karelz commented Sep 15, 2022

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
Copy link
Member

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

@danmoseley
Copy link
Member

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

@JonDouglas
Copy link
Collaborator

@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!

@JonDouglas JonDouglas self-assigned this Sep 19, 2022
@karelz
Copy link
Member

karelz commented Sep 19, 2022

@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
Copy link
Collaborator

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

@leecow
Copy link
Member Author

leecow commented Jan 24, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants