core
core copied to clipboard
dotnet
What's new in .NET 7 Preview 7 [WIP]
What's new in .NET 7 Preview 7
This issue is for teams to highlight work for the community that will release .NET 7 Preview 7
To add content, use a new conversation entry. The entry should include the team name and feature title as the first line as 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 RC1: https://github.com/dotnet/core/issues/7716
Order and OrderDescending
https://github.com/dotnet/runtime/issues/67194
System.Linq now has the methods Order and OrderDescending, which are there to order an IEnumerable according to T.
Also IQueryable supports this now.
Note: This change does not introduce a new language feature to System.Linq.Expressions.
Usage
Previously you had to call OrderBy/OrderByDescending referencing the own value.
var data = new[] { 2, 1, 3 };
var sorted = data.OrderBy(static e => e);
var sortedDesc = data.OrderByDescending(static e => e);
Now you could write:
var data = new[] { 2, 1, 3 };
var sorted = data.Order();
var sortedDesc = data.OrderDescending();
Unix File Modes
Previously .NET had no built in support for getting and setting Unix file permissions, which control which users can read, write, and execute files and directories. PInvoking manually to syscalls is not always easy because some are exposed differently on different distros - for example, on Ubuntu you may have to pinvoke to __xstat, on RedHat to stat. So a first class .NET API is important.
In Preview 7 we introduced a new enum:
public enum UnixFileMode
{
None,
OtherExecute, OtherWrite, OtherRead,
GroupExecute, GroupWrite, GroupRead,
UserExecute, UserWrite, UserRead,
...
}
and APIs File.GetUnixFileMode and File.SetUnixFileMode that get and set the file mode on either a path or a handle (file descriptors). As well as a new property on FileInfo and DirectoryInfo named UnixFileMode.
There is also a new overload of Directory.CreateDirectory and a new property on FileStreamOptions to allow you to create a directory or file with a particular mode in one shot. Note that when you use these, umask is still applied, as it would if you created the directory or file in your shell.
Usage
// Create a new directory with specific permissions
Directory.CreateDirectory("myDirectory", UnixFileMode.UserRead | UnixFileMode.UserWrite | UnixFileMode.UserExecute);
// Create a new file with specific permissions
FileStreamOptions options = new()
{
Access = FileAccess.Write,
Mode = FileMode.Create,
UnixCreateMode = UnixFileMode.UserRead | UnixFileMode.UserWrite,
};
using FileStream myFile = new FileStream("myFile", options);
// Get the mode of an existing file
UnixFileMode mode = File.GetUnixFileMode("myFile");
// Set the mode of an existing file
File.SetUnixFileMode("myFile", UnixFileMode.UserRead | UnixFileMode.UserWrite | UnixFileMode.UserExecute);
References
See https://github.com/dotnet/runtime/pull/69980
A big thank you goes out to @tmds, a long-term contributor from Red Hat, who proposed, designed, and implemented this feature.
ref field support
The .NET 7 runtimes now have full support for ref fields within ByRefLike types (that is, ref struct). There was extensive language design behind this much requested feature that users can read about here. With this feature, types previously requiring specialized handling in the runtimes (for example, Span<T> and ReadOnlySpan<T>), can now be fully implemented in C#.
LibraryImport P/Invoke source generator
The LibraryImport source generator is now available in a supported manner to all users. The culmination of more than 18 months this source generator is designed to be a drop-in replacement for the majority of DllImport uses, both in the runtime product and in user code. The .NET libraries has all adopted LibraryImport and have been shipping with source generated marshalling code since .NET 7 Preview 1.
The source generator ships with the .NET 7 TFM and is readily available for consumption. In order to get the benefit of the source generated marshalling, replace usages of DllImport with LibraryImport. There are Analyzers and Fixers that can assist with this process.
Usage
Before
public static class Native
{
[DllImport(nameof(Native), CharSet = CharSet.Unicode)]
public extern static string ToLower(string str);
}
After
public static partial class Native
{
[LibraryImport(nameof(Native), StringMarshalling = StringMarshalling.Utf16)]
public static partial string ToLower(string str);
}
There is an analyzer and code-fix to automatically convert your DllImport attributes to LibraryImport. For Preview 7, it is opt-in. Add dotnet_diagnostic.SYSLIB1054.severity = suggestion to your EditorConfig file to enable the conversion analyzer as a diagnostic.
References
See https://github.com/dotnet/runtime/issues/60595
Design documentation and details on marshalling custom types can be found under docs/design/libraries/LibraryImportGenerator.
CodeGen
Community PRs (Many thanks to JIT community contributors!)
- @MichalPetryka fixed the issue #71632 in PR #71633 Make getTypeForPrimitiveValueClass treat different signs as different types.
- @shushanhf made 2 fixes in LoongArch64.
- @singleaccretion made 20 PR contributions during Preview 7.
- @SkiFoD optimized to use Min/Max intrinsics if one of arguments is constant (PR #69434).
Arm64
- @a74nh implemented the first part of #67894 in PR #71616 that generates csel and ccmp for conditional comparison and selection instructions (issue #55364).
Loop Optimizations
In preview 7, we made serveral improvements on Loop Optimizations.
- PR #71184 strengthens checking of the loop table for better loop integrity checks as described in #71084.
- PR #71868 Do not compact blocks around loops
- PR #71659 Adjust weights of blocks with profile inside loops in non-profiled methods
- PR #71504 Improvements to loop hoisting
- PR #70271 optimized multi-dimensional array access. It improved the latency by up to 67% (Performance Link).
General Optimizations
- Hot/Cold splitting is enabled for Exception Handling funclets in PR #71236.
System.Security.Cryptography support on WebAssembly
.NET 6 supported the SHA family of hashing algorithms when running on WebAssembly. .NET 7 enables more cryptographic algorithms by taking advantage of SubtleCrypto when possible, and falling back to a .NET implementation when SubtleCrypto can’t be used. In .NET 7 Preview 7 the following algorithms are now supported on WebAssembly:
-
SHA1, SHA256, SHA384, SHA512
-
HMACSHA1, HMACSHA256, HMACSHA384, HMACSHA512
-
Aes (only CBC mode is supported)
-
Rfc2898DeriveBytes (PBKDF2)
-
HKDF
For more information, see dotnet/runtime#40074.
Trimming and NativeAOT Breaking Change
All assemblies trimmed by default
To better align with user expectations and produce smaller and more efficient apps, trimming now trims all assemblies in console apps by default. This change only affects apps that are published with PublishTrimmed=true, and it only affects apps that had existing trim warnings. It also only affects plain .NET apps that don't use the Windows Desktop, Android, iOS, WASM, or ASP.NET SDK.
Previous behavior
Previously, only assemblies that were opted-in with <IsTrimmable>true</IsTrimmable> in the library project file were trimmed.
New behavior
Starting in .NET 7, trimming trims all the assemblies in the app by default. Apps that may have previously worked with PublishTrimmed may not work in .NET 7. However, only apps with trim warnings will be affected. If your app has no trim warnings, the change in behavior should not cause any adverse affects, and will likely decrease the app size.
For example, an app that uses Newtonsoft.Json or System.Text.Json without source generation to serialize and deserialize a type in the user project may have functioned before the change, because types in the user project were fully preserved. However, one or more trim warnings (warning codes ILxxxx) would have been present. Now, types in the user project are trimmed, and serialization may fail or produce unexpected results.
If your app did have trim warnings you may see changes in behavior or exceptions. For example, an app that uses Newtonsoft.Json or System.Text.Json without source generation to serialize and deserialize a type in the user project may have functioned before the change, because types in the user project were fully preserved. However, one or more trim warnings (warning codes ILxxxx) would have been present. Now, types in the user project are trimmed, and serialization may fail or produce unexpected results.
Recommended action
The best resolution is to resolve all the trim warnings in your application. For information about resolving the warnings in your own libraries, see Introduction to trim warnings. For other libraries, contact the author to request that they resolve the warnings, or choose a different library that already supports trimming. For example, you can switch to xref:System.Text.Json?displayProperty=fullName with source generation, which supports trimming, instead of Newtonsoft.Json.
To revert to the previous behavior, set the TrimMode property to partial, which is the pre-.NET 7 behavior.
<TrimMode>partial</TrimMode>
The default .NET 7+ value is full:
<TrimMode>full</TrimMode>
ClientWebSocket upgrade response details
ClientWebSocket previously did not provide any details about upgrade response. However, the information about response headers and status code might be important in both failure and success scenarios.
In case of failure, the status code can help to distinguish between retriable and non-retriable errors (server doesn't support web sockets at all vs. just a tiny transient error). Headers might also contain additional information on how to handle the situation.
The headers are also helpful even in case of a successful web socket connect, e.g., they can contain a token tied to a session, some info related to the subprotocol version, or the server can go down soon, etc.
Usage
ClientWebSocket ws = new();
ws.Options.CollectHttpResponseDetails = true;
try
{
await ws.ConnectAsync(uri, default);
// success scenario
ProcessSuccess(ws.HttpResponseHeaders);
ws.HttpResponseHeaders = null; // clean up (if needed)
}
catch (WebSocketException)
{
// failure scenario
if (ws.HttpStatusCode != null)
{
ProcessFailure(ws.HttpStatusCode, ws.HttpResponseHeaders);
}
}
References
See https://github.com/dotnet/runtime/issues/25918
GC Regions have been enabled for most platforms as part of .NET 7, to help with backward compatibility we are now also including clrgc.dll with runtime packages which can fallback to segments. To use clrgc.dll (aka standalone GC) you can use the following configuration:
COMPLUS_GCName=clrgc.dll
Recent GC optimizations during preview7 have improved working set utilization on linux containers as measured on asp.net TechEmpower benchmarks. For small container scenario (512mb/1000m container) there is a reduction of about 10% (red line: .NET 6 / yellow: .NET 7).
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 = await client.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 https://github.com/dotnet/runtime/issues/70684
@GF-Huang I believe the issue is the enclosing class, InnoSetupHelper, must also be marked partial.
@GF-Huang I believe the issue is the enclosing class,
InnoSetupHelper, must also be markedpartial.
Why the example no partial? And no docs talk about you need /unsafe.
Why the example no partial?
A mistake - I've updated the example above. This specific github issue isn't really an official venue for docs and details. I would focus on the official documentation for features (that is, https://learn.microsoft.com/dotnet/standard/native-interop/pinvoke-source-generation.)
And no docs talk about you need /unsafe.
I thought we had made reference to that. In fact I thought the analyzer or fixer will switch over the project or at least warn/error if unsafe isn't enabled. See applicable errors here. /cc @jkoritzinsky @elinor-fung
The only one docs about LibarayImport I found by google is this: https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke-source-generation?source=recommendations.
It's also there's no class partial code, and no /unsafe. Such documentation is just too bad.