You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is for teams to highlight work for the community that will release .NET 7 Preview 1
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.
@stephentoub reasonable to blog about regex SG in preview 1? If so, we'll need some content - either from @joperezr or yourself, what do you prefer? It's probably worth its own blog post, but for Preview 1, we'll just need a paragraph/screenshot for the release post.
Now that the DllImport generator is in the product too, perhaps we that also deserves a post or at least a mention? @elinor-fung interested in writing up something? I'd imagine it mentions that is what we did and the plan is to make it available to everyone in the future.
We have been making progress on annotating the Microsoft.Extensions.* libraries for nullability. In .NET 7 Preview 1, the following libraries have been annotated for nullability:
You can see the remaining libraries, and follow the progress at dotnet/runtime#43605.
By the time .NET 7 is released, we plan on annotating all the Microsoft.Extensions.* libraries for nullability.
A huge thank you to @maxkoshevoi who has been contributing the bulk of this effort. Without @maxkoshevoi's help, we would not be nearly as far as we are.
Reacted by Maksym Koshovyi, Rogier van der Hee, Eric StJohn, Jeff Handley, Reilly Wood, Greg Ingram, Allan Targino, Mahesh Bongani, Lilly Sieberer, Giorgi Chakhidze and 8 more
We integrated the p/invoke source generator that was prototyped in .NET 6 into dotnet/runtime and have been converting the runtime libraries to use it. This means the converted p/invokes are AOT-compatible and no longer require an IL stub to be generated at runtime.
We intend to make the p/invoke source generator available for use outside the runtime in the future. You can follow our remaining work in dotnet/runtime#60595.
Reacted by Reilly Wood, AraHaan, dimohy, Lilly Sieberer, Giorgi Chakhidze, Austin Drenski, MoNa, Oleksandr Mazyaka, Boring3 and Aloento
In addition, we may completely remove support for non-Windows platforms in a future release, even if you enable it using the runtime configuration switch.
Reverted Console Formatter Change in ASP.NET Core Container Images
In .NET 6, the Logging__Console__FormatterName environment variable was explicitly set to Json in the aspnet container images. Based on usability issues and your feedback, we've reverted this change in .NET 7.
This is a breaking change. If you relied on this environment variable being set to Json for your application, you'll need to explicitly set it yourself in your Dockerfile:
ENV Logging__Console__FormatterName=Json
Reacted by Austin Drenski, petrformanek and Weihan Li
Ever wished you had all of the great benefits that come from having a specialized Regex engine that is optimized for your particular pattern, without having to pay the costs of building this engine at runtime? We are excited to announce the new Regex Source Generator which is included in Preview 1. It brings all of the performance benefits from our Compiled engine without the startup cost, and it has additional benefits, like providing a great debugging experience as well as being trimming-friendly. If your pattern is known at compile-time, then the new regex source generator is the way to go.
In order to start using it, you only need to turn the containing type into a partial one, and declare a new partial method with the RegexGenerator attribute that will return the optimized Regex object, and that's it! The source generator will fill the implementation of that method for you, and will get updated automatically as you make changes to your pattern or to the additional options that you pass in. Here is an example:
publicpartialclassFoo// <-- Make the class a partial class{[RegexGenerator(@"abc|def",RegexOptions.IgnoreCase)]// <-- Add the RegexGenerator attribute and pass in your pattern and optionspublicstaticpartialRegexMyRegex();// <-- Declare the partial method, which will be implemented by the source generatorpublicboolBar(stringinput){boolisMatch=MyRegex().IsMatch(input);// <-- Use the generated engine by invoking the partial method.// ..}}
And that's it. Please try it out and let us know if you have any feedback.
Reacted by Stephen Toub, cschulzsuper, Uwe Keim, dimohy, OmariO, Marc Terhorst, Lucimarck J S Dias, Mrxx99, Mohsen Rajabi, Lilly Sieberer and 17 more
Reacted by Boring3
Reacted by Reilly Wood, YohanS, Steve, Eirik Tsarpalis, Uwe Keim, Lucimarck J S Dias, Martin Costello, Giorgi Chakhidze, Austin Drenski, Akif Faruk Nane and 6 more
Reacted by Boring3 and I Freeman-Yates
Reacted by Reilly Wood, Maksym Koshovyi, Uwe Keim, hanabi1224, Lucimarck J S Dias, Sveinung, Austin Drenski, Akif Faruk Nane, Boring3 and Laurent Keusch
In addition, we may completely remove support for non-Windows platforms in a future release, even if you enable it using the runtime configuration switch.
I am reading this as there is no plans to continue attempts to make forms cross-platform, or anything that relies on system.drawing? What was the point of Microsoft taking over the open-source initiatives to make .NET cross-platform, shut down Net Framework by merging in Core only to decide to drop the cross platform support?
Hello @ajhiggins421, there has never been the plan to make Windows Forms cross-platform; even after it got ported to modern .NET it remains a Windows-only technology. The first link of the post you quoted gives more details about why System.Drawing.Common became Windows-only, and also provides a list of cross-platform alternatives.
If you have any more questions I suggest you reply to dotnet/runtime#64084 or open a new issue on dotnet/runtime instead of replying here; people that might be subscribed to it will get excessive notifications.
Reacted by Dan Moseley, Reilly Wood, Santiago Fernandez Madero, Steve, Aloento and Laurent Keusch
Correct, Windows Forms and System.Drawing are essentially Windows tech, as they're wrappers over Windows tech. For cross platform UI, you should take a look at MAUI which is being built for that purpose.
Sorry for the confusion but AFIAK Microsoft does to support Maui on Linux. See: .NET MAUI Layouts Revamped, Developers Question Lack of Linux. Additionally, It is not removal of System.Drawing that draws my concern but that by removing the library it indicates there are no plans to provide Linux desktop support at all, ever.
After program manager David Ortinau confirmed that "we do not support Linux as a development environment for .NET MAUI," Microsoft exec Richard Lander said, "It would be good knowing how many people would benefit from/need Linux environment support for development."
To which a developer responded: "I do agree. And generally I'm sure that Microsoft will be able to find out the answer in case it feels like it needs to. However since '.NET is Free. Cross platform. Open source' and also 'Supported on Linux, Windows, and macOS' and MAUI is .NET, avoiding Linux support brings some dissonance. I was given tools (C#/F#, .NET), but I can't use them. Not to mention that most popular cross platform UI frameworks do support Linux. So question arises."
I was under the impression the revamping of DotNet under core was to make the framework cross-platform and while specifics on surface areas were not given, I was under the impression except were explicitly stated functionality would be ported. For those not being ported an alternative was being developing, such as WCF and GRPC. I understand Windows.Forms relies on the Internal Windows API. I, and I assume most of the developer community as a whole, was under the impression we would get Linux desktop application at some point. Perhaps, similar to how we were given other Microsoft.* libraries, such as Microsoft.Data.SqlClient.
Again, I have repeatedly read Microsoft does not support Maui on Linux. So is the developer community to take the removal of System.Drawing as confirmation that there are no plans from Microsoft desktop support short of the community providing one. It's not just System.Drawing either. I am seeing other components that gave Linux support, like Mono, being carved out of various libraries moving toward 7. It is almost as if Microsoft is backtracking on its commitment for to Linux support.
Reacted by Reilly Wood, Kristoffer Strube and Steve
I personally would love to see MAUI supporting Linux to compete with, e.g., Flutter, but I understand the importance of prioritizing the other operating systems which have a much larger market share.
I personally would love to see MAUI supporting Linux to compete with, e.g., Flutter, but I understand the importance of prioritizing the other operating systems which have a much larger market share.
Flutter is using Skia to draw controls manually, while MAUI is more about wrapping the platform native controls and abstracting them in a cross-platform way, which can provide much better performance, accessibility and integration, and also enable the ability to draw cross-platform controls using Microsoft.Maui.Graphics.
Windows, macOS, Android and iOS, all of them have their own unified native graphic interface and controls, but I don't think Linux has such an interface to provide those controls across all distributions out-of-box.
In theory it's possible to build MAUI for Linux on a specific graphics interface provided by the community, such as GTK, but it's not a build-in component in the system so it's hard to be taken as an official solution.
Activity
danmoseley commentedon Jan 20, 2022
@stephentoub reasonable to blog about regex SG in preview 1? If so, we'll need some content - either from @joperezr or yourself, what do you prefer? It's probably worth its own blog post, but for Preview 1, we'll just need a paragraph/screenshot for the release post.
stephentoub commentedon Jan 20, 2022
We can if you think now's a good time.
AaronRobinsonMSFT commentedon Jan 24, 2022
Now that the DllImport generator is in the product too, perhaps we that also deserves a post or at least a mention? @elinor-fung interested in writing up something? I'd imagine it mentions that is what we did and the plan is to make it available to everyone in the future.
eerhardt commentedon Jan 24, 2022
.NET Libraries: Nullable annotations for Microsoft.Extensions
dotnet/runtime#43605
We have been making progress on annotating the Microsoft.Extensions.* libraries for nullability. In .NET 7 Preview 1, the following libraries have been annotated for nullability:
You can see the remaining libraries, and follow the progress at dotnet/runtime#43605.
By the time .NET 7 is released, we plan on annotating all the Microsoft.Extensions.* libraries for nullability.
A huge thank you to @maxkoshevoi who has been contributing the bulk of this effort. Without @maxkoshevoi's help, we would not be nearly as far as we are.
tarekgh commentedon Jan 24, 2022
Observability
Continue improving the tracing APIs:
ActivityContext.TryParseallows parsing and creating anActivityContextobject including if the activity context was propagated from a remote parent. ActivityContext.TryParse should support IsRemote runtime#42575Activity.IsStopped()to indicates whether theActivityobject is stopped. [API Proposal]: Activity.IsStopped (functionality required to conform to OpenTelemetry specification) runtime#63353JulieLeeMSFT commentedon Jan 25, 2022
CodeGen
Community PRs (Many thanks to JIT community contributors!!)
From @am11
From @anthonycanino
From @SeanWoo
From @SingleAccretion
emitOutputAMruntime#62896OperIsLocalruntime#63253gtHasRefpay attention to LCL_FLD nodes runtime#62568GT_LCL_FLDruntime#61209fgMemoryVNForLoopSideEffectsruntime#60505From @RalfKornmannEnvision
From @weilinwa
Dynamic PGO
Arm64
-- 61030 and 63422: SIMDfying MemCopy and MemSet instructions sequences and allowing the JIT to unroll such sequences (instead of using a helper call) up to 128 bytes on Arm64 (it was 64 bytes before the change)
Loop Optimizations
General Optimizations
elinor-fung commentedon Jan 26, 2022
Interop: P/Invoke source generation
dotnet/runtime#60212
dotnet/runtime#60595
We integrated the p/invoke source generator that was prototyped in .NET 6 into dotnet/runtime and have been converting the runtime libraries to use it. This means the converted p/invokes are AOT-compatible and no longer require an IL stub to be generated at runtime.
We intend to make the p/invoke source generator available for use outside the runtime in the future. You can follow our remaining work in dotnet/runtime#60595.
eiriktsarpalis commentedon Jan 27, 2022
New APIs in System.Text.Json
System.Text.Json ships with a couple of minor quality-of-life enhancements:
JsonSerializerOptionssingleton used internally by System.Text.Json.JsonWriterOptions.MaxDepthproperty and ensure this value flows from the equivalentJsonSerializerOptions.MaxDepthproperty on serialization.Patchmethods toSystem.Net.Http.Json.lambdageek commentedon Jan 28, 2022
Mono: Hot Reload
Tracking issue: dotnet/runtime#57365
staticlambdas to existing methodsthisto existing methods that already have at least one lambda that capturesthisstaticor non-virtualinstance methods to existing classessafern commentedon Feb 1, 2022
System.Drawing.Common: Unix support dropped
Based on the .NET 6 announcement made in: https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/system-drawing-common-windows-only
We removed support for that switch in 7.0-preview1: dotnet/runtime#64084
mthalman commentedon Feb 8, 2022
Reverted Console Formatter Change in ASP.NET Core Container Images
In .NET 6, the
Logging__Console__FormatterNameenvironment variable was explicitly set toJsonin theaspnetcontainer images. Based on usability issues and your feedback, we've reverted this change in .NET 7.This is a breaking change. If you relied on this environment variable being set to
Jsonfor your application, you'll need to explicitly set it yourself in your Dockerfile:ENV Logging__Console__FormatterName=Jsonjoperezr commentedon Feb 11, 2022
Introducing the new Regex Source Generator
dotnet/runtime#44676
Ever wished you had all of the great benefits that come from having a specialized Regex engine that is optimized for your particular pattern, without having to pay the costs of building this engine at runtime? We are excited to announce the new Regex Source Generator which is included in Preview 1. It brings all of the performance benefits from our Compiled engine without the startup cost, and it has additional benefits, like providing a great debugging experience as well as being trimming-friendly. If your pattern is known at compile-time, then the new regex source generator is the way to go.
In order to start using it, you only need to turn the containing type into a
partialone, and declare a new partial method with theRegexGeneratorattribute that will return the optimizedRegexobject, and that's it! The source generator will fill the implementation of that method for you, and will get updated automatically as you make changes to your pattern or to the additional options that you pass in. Here is an example:Before:
After:
And that's it. Please try it out and let us know if you have any feedback.
ajhiggins421 commentedon Feb 15, 2022
I am reading this as there is no plans to continue attempts to make forms cross-platform, or anything that relies on system.drawing? What was the point of Microsoft taking over the open-source initiatives to make .NET cross-platform, shut down Net Framework by merging in Core only to decide to drop the cross platform support?
teo-tsirpanis commentedon Feb 15, 2022
Hello @ajhiggins421, there has never been the plan to make Windows Forms cross-platform; even after it got ported to modern .NET it remains a Windows-only technology. The first link of the post you quoted gives more details about why
System.Drawing.Commonbecame Windows-only, and also provides a list of cross-platform alternatives.If you have any more questions I suggest you reply to dotnet/runtime#64084 or open a new issue on
dotnet/runtimeinstead of replying here; people that might be subscribed to it will get excessive notifications.danmoseley commentedon Feb 15, 2022
Correct, Windows Forms and System.Drawing are essentially Windows tech, as they're wrappers over Windows tech. For cross platform UI, you should take a look at MAUI which is being built for that purpose.
KPixel commentedon Feb 15, 2022
Specifically, Microsoft.Maui.Graphics is the cross-platform graphics library of the future.
ajhiggins421 commentedon Feb 16, 2022
Sorry for the confusion but AFIAK Microsoft does to support Maui on Linux. See: .NET MAUI Layouts Revamped, Developers Question Lack of Linux. Additionally, It is not removal of
System.Drawingthat draws my concern but that by removing the library it indicates there are no plans to provide Linux desktop support at all, ever.I was under the impression the revamping of DotNet under core was to make the framework cross-platform and while specifics on surface areas were not given, I was under the impression except were explicitly stated functionality would be ported. For those not being ported an alternative was being developing, such as WCF and GRPC. I understand
Windows.Formsrelies on the Internal Windows API. I, and I assume most of the developer community as a whole, was under the impression we would get Linux desktop application at some point. Perhaps, similar to how we were given otherMicrosoft.*libraries, such asMicrosoft.Data.SqlClient.Again, I have repeatedly read Microsoft does not support Maui on Linux. So is the developer community to take the removal of System.Drawing as confirmation that there are no plans from Microsoft desktop support short of the community providing one. It's not just
System.Drawingeither. I am seeing other components that gave Linux support, like Mono, being carved out of various libraries moving toward 7. It is almost as if Microsoft is backtracking on its commitment for to Linux support.danmoseley commentedon Feb 16, 2022
cc @davidortinau
ThatRendle commentedon Feb 23, 2022
@ajhiggins421 If you look at the Supported Platforms specifically for Microsoft.Maui.Graphics you'll see that it does support Linux via an abstraction over SkiaSharp. While the complete MAUI platform does not target Linux (yet?), there's no sign of them dropping Linux support from the Graphics component.
I personally would love to see MAUI supporting Linux to compete with, e.g., Flutter, but I understand the importance of prioritizing the other operating systems which have a much larger market share.
hez2010 commentedon Feb 23, 2022
Flutter is using Skia to draw controls manually, while MAUI is more about wrapping the platform native controls and abstracting them in a cross-platform way, which can provide much better performance, accessibility and integration, and also enable the ability to draw cross-platform controls using Microsoft.Maui.Graphics.
Windows, macOS, Android and iOS, all of them have their own unified native graphic interface and controls, but I don't think Linux has such an interface to provide those controls across all distributions out-of-box.
In theory it's possible to build MAUI for Linux on a specific graphics interface provided by the community, such as GTK, but it's not a build-in component in the system so it's hard to be taken as an official solution.
leecow commentedon Jan 24, 2023
.NET 7 GA is available. Closing these pre-release issues.