Announcing .NET 7 Preview 1
Today, we are excited to announce the next milestone in the history of .NET. While celebrating the community and 20 years of innovation, .NET 7 Preview 1 marks the first step forward towards the next 20 years of .NET.
ASP.NET Core Preview 1 and EF7 Preview 1 are also released today.
.NET 7 builds on the foundation established by .NET 6, which includes a unified set of base libraries, runtime, and SDK, a simplified development experience, and higher developer productivity. Major areas of focus for .NET 7 include improved support for cloud native scenarios, tools to make it easier to upgrade legacy projects, and simplifying the developer experience by making it easier to work with containers.
.NET 7 Preview 1 includes annotations to APIs to support nullability, ongoing JIT compiler optimizations, new APIs, and support for more hot reload scenarios.
Releases of .NET include products, libraries, runtime, and tooling, and represent a collaboration across multiple teams inside and outside Microsoft. The broader themes covered in this blog post do not encompass all of the key scenarios and investments for .NET 7. They represent large areas but are just a part of all the important work going into .NET 7. We plan to make broad investments in ASP.NET Core, Blazor, EF Core, WinForms, WPF, and other platforms. You can learn more about these areas by reading the product roadmaps:
You can download .NET 7 Preview 1, for Windows, macOS, and Linux.
.NET 7 has been tested with Visual Studio 17.2 Preview 1. We recommend you use the preview channel builds if you want to try .NET 7 with Visual Studio family products. Visual Studio for Mac support for .NET 7 previews isn’t available yet but is coming soon.
Modern client: .NET Multi-platform App UI (.NET MAUI)
.NET MAUI is the future of cross-platform native UI with .NET and will be a part of .NET 7. On Tuesday, we released .NET MAUI Preview 13. We’re currently focused on shipping .NET MAUI support for .NET 6 and we expect to ship a release candidate (RC) soon. After we have an RC available, we will focus on shipping additional RCs until we reach the quality desired for general availability (GA). After .NET MAUI GA has shipped for .NET 6, we’ll include it in .NET 7 and look at improving the inner development loop experience, supporting the latest .NET SDK tooling, faster app performance, sharing more code, and an enhanced interop story. Check out the status of .NET MAUI and project roadmap for more information.
Modern cloud: Cloud Native and containers
Cloud native apps are built from the ground up to take advantage of modern, web-based resources such as database services and hosted containers. The cloud native architecture can improve scale in large applications by creating autonomous subsystems (commonly referred to as microservices) that are deployed and scale independently from other areas of the application while lowering costs in the long term. The microservices architecture is a popular approach because it’s flexible and designed to evolve and scale to limits that are difficult to achieve in a monolithic architecture.
.NET 7 will make it easier to build cloud native apps by exploring improvements to the developer experience, such as:
- Simplifying the setup and configuration necessary to implement secure authentication and authorization
- Improving the performance of application startup and runtime execution.
We’ll continue to make investments in Orleans, a .NET cross-platform framework for building distributed applications that has been referred to as “distributed .NET.” We’ll continue to enhance the comprehensive documentation for Orleans and make it easier to use and implement by improving integration of Orleans with existing cloud services like Azure App Services and Azure Container Apps.
Containers are the preferred way to deploy cloud native apps and microservices for many companies today. Relying on containers presents several challenges including managing compliance, building and publishing images, securing images, and streamlining the size and performance of images. We believe that there is an opportunity to create a better experience with .NET containers.
To help customers face these challenges, we plan to make significant improvements to .NET development with containers in .NET 7. For example, we’ll explore building containers directly via MSBuild as a new capability of the SDK. We plan to enhance telemetry to improve the observability of containers. We’ll also focus on making our container images smaller, faster, and more secure while we explore highly requested models such as rootless and distroless.
Modernize: upgrade .NET apps
Since the release of .NET 6, developers have been upgrading their applications to take advantage of new performance gains, productivity features like minimal APIs and hot reload, new runtime and C# language innovations and the availability of a mature ecosystem of libraries and tools. In .NET 7, we’ll continue to enable you to bring your existing .NET apps forward to the latest .NET platforms and technologies. More analyzers, code fixers, and support for additional app types in the .NET Upgrade Assistant will help you confidently upgrade even more of your application portfolio and spend less time on the repetitive tasks involved in upgrading.
We also know that each of the .NET app models (ASP.NET, WinForms, WPF, etc.) have their own unique challenges with modernization and may be lacking functionality that you need as a developer or support in the platform itself. For some of these, like WCF, there may not be a clear direction for you. We’ll focus on offering appropriate guidance, documentation, and tooling to make these .NET app models easier to upgrade.
.NET 7 is a Current 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 between LTS and Current releases is the length of support. For more about .NET support policies, see the .NET and .NET Core official support policy.
You can find the most recent list of breaking changes in .NET 7 by reading the Breaking changes in .NET 7 document. It lists breaking changes by area and release with links to detailed explanations.
To see what breaking changes are proposed but still under review, follow the Proposed .NET Breaking Changes GitHub issue.
The following features are now available in the Preview 1 release.
Nullable annotations for Microsoft.Extensions
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:
By the time .NET 7 is released, we plan on annotating all the Microsoft.Extensions.* libraries for nullability. You can see the remaining libraries, and follow the progress at dotnet/runtime#43605.
A huge thank you to @maxkoshevoi who has been contributing the bulk of this effort. Without @maxkoshevoi’s help, we wouldn’t be nearly as far as we are.
Continue improving the tracing APIs:
- Adding the overload to
ActivityContext.TryParseallows parsing and creating an
ActivityContextobject including if the activity context was propagated from a remote parent (related issue).
- Adding the method
Activity.IsStopped()to indicate whether the
Activityobject is stopped(related issue).
Community PRs (many thanks to JIT community contributors!!)
- Tune floating-point CSEs live across a call better runtime#63903
- Update hash of the new CSE when resizing runtime#61984
- Rewrite selection for fields and always normalize SIMD types in VN runtime#61370
- Add documentation on how VN numbers memory runtime#60476
- Improve value numbering for casts runtime#59841
- Address-expose locals under complex local addresses in block morphing runtime#63100
- Handle embedded assignments in copy propagation runtime#63447
- Exception sets: debug checker & fixes runtime#63539
- Implement the “moffset” encoding size optimization in emitOutputAM runtime#62896
- Compress operand kinds array and optimize OperIsLocal runtime#63253
- Make gtHasRef pay attention to LCL_FLD nodes runtime#62568
- Enable global constant propagation for GT_LCL_FLD runtime#61209
- Enable global constant propagation for small types runtime#57726
- Properly type primary selectors in fgMemoryVNForLoopSideEffects runtime#60505
- OSR support for Arm64
- JIT: support OSR for synchronized methods
- JIT: handle interaction of OSR, PGO, and tail calls
- Add 2009 Jit Architecture Plan (excerpts)
- JIT: limited version of forward substitution for some relops
- JIT: save generics context for late devirtualization
- Arm64: Memory barrier improvements
- Use SIMD operations in InitBlkUnroll/CopyBlkUnroll and increase unroll limit up to 128 bytes
- [Arm64] Keep unrolling InitBlock and CopyBlock up to 128 bytes
- ‘cmeq’ and ‘fcmeq’ Vector64.Zero/Vector128.Zero ARM64 containment optimizations
- [arm64] JIT: X % 2 == 0 -> X & 1 == 0
- [arm64] JIT: Add with sign/zero extend
- [arm64] JIT: Enable CSE/hoisting for “arrayBase + elementOffset”
- [arm64] JIT: Fold “A * B + C” to MADD/MSUB
- Accelerate additional cross platform hardware intrinsics
- Implement Narrow and Widen using SIMDAsHWIntrinsic
- Add IsKnownConstant jit helper and optimize ‘str == “”‘ with str.StartsWith(‘c’)
- Allow JIT to keep HFA/HVA in the registers when passing them as argument/returning values
- Enable support for nint/nuint for Vector64/128/256
- Adding support for X86Base.Pause() and ArmBase.Yield()
- Use preferred region from PAL for JIT reloc hints
- Support fast tailcalls in R2R
- Allow contained indirections in tailcalls on x64
- Optimize indirection cell call sequences more generally
- Avoid additional local created for delegate invocations
Interop: p/Invoke code generation
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.
New APIs in System.Text.Json
System.Text.Json ships with a couple of minor quality-of-life enhancements:
- Developers now have access to the default
JsonSerializerOptionssingleton used internally by System.Text.Json (related issue).
- Add a
JsonWriterOptions.MaxDepthproperty and ensure this value flows from the equivalent
JsonSerializerOptions.MaxDepthproperty on serialization (related issue).
Hot reload improvements
The following edits are now allowed in C# hot reload for Blazor WebAssembly and .NET for iOS and Android (related issue):
- Adding static lambdas to existing methods
- Adding lambdas that capture this to existing methods that already have at least one lambda that captures this
- Adding new static or non-virtual instance methods to existing classes
- Adding new static fields to existing classes
- Adding new classes
- Instance fields in newly added classes are not supported
- Newly added methods and fields in existing or new classes are not visible to reflection
You can follow our progress in dotnet/runtime#57365
Targeting .NET 7
To target .NET 7, you need to use a .NET 7 Target Framework Moniker (TFM) in your project file. For example:
The full set of .NET 7 TFMs, including operating-specific ones follows.
We expect that upgrading from .NET 6 to .NET 7 should be straightforward. Please report any breaking changes that you discover in the process of testing existing apps with .NET 7.
A global and diverse team of engineers at Microsoft in collaboration with a highly engaged community of developers are building .NET 7. The broad .NET community, including everyone from students and hobbyists to open-source contributors and enterprise customers, are at the heart of .NET. They propose new ideas, contribute code regularly, and drive the .NET ecosystem forward. We appreciate and thank you for your support, contributions and insights.
Welcome to .NET 7.
That’s the biggest issue I have with .NET actually. There were so many cool features announced like trimming, AOT etc. While the runtime gets support, Winforms and WPF for example don’t. It’s not even mentioned on any roadmap. Instead of bringing everything to the same level, we got a hell of UI development. Winforms and WPF not getting newest features. WinUI and Maui are super buggy, unstable and slow in development. .NET turns into a language for libraries console or web application projects.
And because the future is very unclear I wouldn’t recommend .NET for anything else right now. Microsoft would do itself a favor if the next version of .NET would bring all at the same level instead of putting tons of work into .NET runtime but zero work in everything else. Developers would have a guarantee that .NET is safe to use for the future then.
I feel .net is much hard to use in those “mordern” days, MS introduc webForm winform in a few month/years, and also WPF MVC WCF in a few years, but if you look at the current product road-map , the “same feature” need years to complete, and the “new ways/framework” come and drop in years.
and some product doing almost the same thing, for example winform and WPF and MAUI and WinUI ,there no clear upgrade roadmap for us because each of them lack of previous feature and may also need each other. you know flutter now support windows as an framework born after Xamarin born 10 years and there is also a QT framework. no other product facing the “winform/wpf/winui/uwp” choice issue .
I simple called those “dispersion” （get 10 man and make each of them develop each product and the feature is almost the same, as the result is 1 man maintenance 1 product）
I lost all hope in what concerns GUIs coming from Microsoft, the whole Windows 8 => 8.1 (UAP) => 10 (UWP) => 10 (WinUI 3.0), dropping .NET Native and C++/CX on the floor, have burned all bridges to new GUI frameworks, Forms and WPF are good enough going forward.
Even MAUI is a big disappointment with their shortcuts to use Catalyst instead of proper macOS APIs, not even VS for Mac team is using it for their rewrite rahter Xamarin.Mac.
Having used .NET since version 1 beta for all kind of development (web, desktop, APIs) I think that nowadays you can use it safely only for the backend APIs and for simple web applications using MVC.
I had bad experiences with Blazor, Xamarin and the whole UWP/UAP/WinUI shenanigans.
As a software architect, I continue to defend and promote .NET for new projects but it seems that more and more the stack we are using is something like that:
– .NET for the API backend and data access with EF.
– Angular for the web frontend.
– Flutter for the mobile frontend.
I think that Microsoft should really focus on offering a viable frontend technology for web, desktop and mobile frontend development.
Me too, .NET looks like it is in a turmoil, of internal teams fighting for resources, while they try to sell us half backed framework replacements that don’t offer even half of the functionality of the existing frameworks.
Example, if Microsoft wants us to take WinUI 3.0 seriously, give us a designer, 1:1 feature parity across the WPF API surface, don’t make us write boilerplate in C# for what WPF does out of the box in XAML, and above all, if there are Windows APIs where they force us to use C++ and write COM/UWP components by hand, at very least provide modern tooling at the same level of C++/CX (C++/CLI), instead of make us write boilerplate code like in the bad old OLE 2.0 days.
Completely agree! I’ve been posting on these boards for a long time with the same message, and no Microsoft person EVER responds. The WPF repo is a joke. How many BILLIONS did Microsoft make in the last QUARTER?? And they can’t afford some developers to work on WPF. But they expect everyone to embrace MAUI with open arms.
I completely agree. I am so surprised WinForms seems to get even more love than WPF! The WPF github repo is completely dead! Winforms has managed to need less memory with dotnet 6 which I think is a great achievement!
Unfortunately all our investments of 10 years are in WPF. It works “fine”, but why can Winforms receive love with dotnNet 6 and not WPF?
MAUI may be good for mobile applications, but which serious company will use it for real LOB-applications?
The UI framework story from Microsoft during the last couple of years is, well a joke…
Only place where you are wrong is that it’s good for web. They ruined that also.
I am going to have to agree. Aside from Blazor and EF, I haven’t been too happy with the lack of direction for the other application frameworks. All of the Windows 8/10/11 generation UI frameworks have been a confusing mess. WPF and WinForms somehow still win out. And as far as mobile goes, I prefer Uno to Xamarin/MAUI; and that isn’t really a Microsoft product. :-/
Needless to say, the UI frameworks are sorely in need of direction (and probably staff).
WPF is very good, it should become a multiplatform solution for at least desktop apps. Avalonia is basically that and does the job very well.
Ahead Of Time
Attack On Titan
Can you publish documentation or a blog post on the Microsoft.Extensions.* packages? I’ve never heard of most of those. You can write the greatest code in the world- if you don’t publicize it and thus no one uses it it’s ultimately useless.
Also will there be information about the new C# preview?
Various libraries and APIs exist in that namespace. The documentation is specific to each implementation. For example, Microsoft.Extensions.Logging is documented in Logging in .NET and Microsoft.Extensions.DependencyInjection is documented in Dependency injection in .NET. A high-level reference is available via the API browser.
Honestly its very hard to dig into the extension docs. While logging and dep-inj might be documented “quite thorougly” others are definitely not (composition). It would be nice if more invest is done in also documenting these with examples.
.NET 6 has several noticeable improvements particularly on performance but without MAUI and official Blazor standard controls, it’s still a disappointment.
Hope .NET 7 will redeem itself. Hope that Microsoft will throw much needed investment into MAUI and Blazor to make these a top choice for making applications. I can’t fathom how a huge corporation with billions of dollars of net revenue but still acting like a poor startup that couldn’t afford to pay enough to construct the very foundations that hold Microsoft up for the next 10 to 20 years? It just defies all common senses.
I really hope we can get a designer for WinUI/MAUI. Live preview is cool but is not a replacement for it.
I think that if it was possible to have one, we would have it long time ago in Xamarin. Hot reload got a lot of improvements but yeah, designer is still better.
this comment has been deleted.
The designer is being tracked in this discussion: WinUI 3.0 XAML Designer.
I believe WinUI 3.0 unpackaged apps has been a goal as well. Any updates on this?
WPF roadmap for .NET 7 ?
When I look at the link you have – https://github.com/dotnet/wpf/blob/main/roadmap.md – and search for .NET 7, there is no result.
Looking at the table I do not see any info for .NET 7.0, just either ongoing activities not refreshed for .NET 7.0 – someone in the team spending 3 minutes to update the wording would have been a minimum – or some project management items – review & testing.
So the conclusion from my side, is there is no ‘roadmap’ for WPF in .NET 7.0 other than you will get some defects fixed ?
So, no news about AOT?
This “modern” stuff is a joke. What is “modern”? Make everything run in the cloud where Microsoft can make money off it? You aren’t making things better. Why doesn’t your cross platform UI run on Linux? This will just be a repeat of Silverlight. Dropped in a few years after everyone rejects it. You should be making development easier. You aren’t. That’s the bottom line. You should have kept Web Forms instead of parroting Ruby On Rails.
I would rather the time was spent on extending .NET to cover things left behind with the .NET Framework, like webforms, which has a massive user base. Aside from the huge amount of legacy code, there are many developers like myself who despite having experience in Blazor and MVC, still appreciate the role it plays. It is still the best way to create complex form interfaces without a bunch of flakey clientside code and exposed APIs.
If winforms can be ported to .NET core, I really don’t see why webforms could not be approached in a similar way. While the programmers at Microsoft might not like webforms, many of their customers do. It’s a unique product, there is really nothing else comparable, for those that use it, it’s the best tool for the job.
Perhaps the biggest negative in choosing Microsoft technology is the tendency they have to discontinue things, effectively forcing customers to bin huge amounts of code and invest in pointless rewriting of entire codebases that provides no real benefit. I’m certainly not going to put any effort into projects in Blazor, if Microsoft would kill webforms with the massive user base that has, then killing of Blazor would be nothing for them.
And what happens to the UWP now?
I have same question.
Wasn’t UWP formally killed off like 2 years ago? I thought WinUI is meant to be the end-all next-gen UI framework.