Announcing .NET Framework 4.8.1
We are excited to announce the release of the .NET Framework 4.8.1 today. It’s included in the Visual Studio 2022 17.3 release and .NET Framework 4.8.1 is also available to download for Windows 10 Version 20H2+ and Windows Server 2022+.
You can install .NET Framework 4.8.1 from our .NET Framework Download site. For building applications targeting .NET Framework 4.8.1, you can download the NET Framework 4.8.1 Developer Pack. If you just want the runtime, you can use either:
- .NET Framework 4.8.1 Web Installer – requires an internet connection during installation
- .NET Framework 4.8.1 Offline installer – can be downloaded and installed later in a disconnected state
Additionally, .NET Framework 4.8.1 is included in the latest version of Visual Studio, Visual Studio 2022 17.3.
.NET Framework 4.8.1 includes native support for the Arm64 architecture (Windows 11+) and accessibility improvements as well as other improvements. You can see the complete list of improvements in the .NET Framework 4.8.1 release notes.
Supported Windows Versions
Windows Client versions: Windows 11, Windows 10 version 21H2, Windows 10 version 21H1, Windows 10 version 20H2
Windows Server versions: Windows Server 2022
New Features in .NET Framework 4.8.1
Native support for Arm64
.NET Framework 4.8.1 adds native Arm64 support to the .NET Framework family. So, your investments in the vast ecosystem of .NET Framework apps and libraries can now leverage the benefits of running workloads natively on Arm64 for better performance when compared to running x64 code emulated on Arm64.
WCAG2.1 compliant accessible tooltips
Microsoft has a commitment to providing products and platforms that are accessible to everyone. .NET Framework 4.8.1 provides two Windows UI development platforms, both of which provide developers with the support necessary to create accessible applications for their users. Over the past several releases, both Windows Forms and WPF have added several features and fixed numerous reliability issues related to accessibility. You can read more about the details of what we fixed or added in each release by visiting What’s new in accessibility in .NET Framework.
In this release, both Windows Forms and WPF have made improvements to the handling of tooltips to enable them to be more accessible. In both cases, tooltips now comply with the guidelines set forth in the WCAG2.1 content on Hover or Focus guidance. The requirements for tooltips require the following:
- Tooltips must display either via mouse hover or by keyboard navigation to the control.
- Tooltips should be dismissable. That is, a simple keyboard command like the ESC key should dismiss the tooltip.
- Tooltips should be hoverable. Users should be able to place their mouse cursor over the tooltip. This enables scenarios like using magnifier to be able to read the tooltip for low-vision users.
- Tooltips should be persistent. Tooltips should not automatically disappear after a certain time has elapsed. Rather, the tooltips should be dismissed by the user moving their mouse to another control, or by dismissing the tooltip as described above.
In WinForms, this support is only available on Windows 11 or higher operating system. WinForms is a thin managed wrapper around the Windows API, and the new tooltip behavior only became available in Windows 11. WPF has no operating system version dependencies for their accessible tooltips.
WPF had implemented most of the requirements for WCAG2.1 compliant tooltips in .NET Framework 4.8. In this release WPF improved the experience by ensuring that a tooltip in the current window can easily be dismissed by using the ESC key, the CTRL key (by itself), or by the combination Ctrl+Shift+F10. The scope of the Escape key was reduced in this release to apply only to the current window, when previously it would have been any open tooltip in the application.
Windows Forms – Accessibility Improvements
Windows Forms was the first Windows UI stack created for .NET Framework. As such, it was originally created to utilize legacy accessibility technology, which doesn’t meet current accessibility requirements. In this release, WinForms has addressed a number of issues. For a complete list of the accessibility related changes, visit What’s new in accessibility in .NET Framework
. Here we’ll focus on the highlights of what WinForms has done in .NET Framework 4.8.1.
- Text Pattern Support– In this release, WinForms added support for the UIA Text Pattern. This pattern enables assistive technology to traverse the content of a TextBox or similar text-based control letter by letter. It enables text to be selected within the control and changed, as well as new text inserted at the cursor. WinForms added this support for TextBox, DataGridView cells, ComboBox controls and more.
- Addressing Contrast issues– We’ve addressed high contrast issues in several controls and have changed the contrast ratio of selection rectangles to be darker and more visible.
- Fixed several DataGridView issues– In this release, we’ve updated the scrollbar names to be consistent. We’ve addressed an issue where Narrator was unable to focus on empty DataGridView cells. Developers are now able to set the localized control type property for Custom DataGridView cells. The link color for DataGridViewLink cells has been updated to have better contrast with the background.
|Symptoms||The .NET Framework 4.x WCF optional components on Windows 11 ARM64 client machines will fail to be enabled either through the dism command or add/remove program UI.|
|Workaround||No workaround available|
|Resolution|| A resolution to this issue will be included in an upcoming release
Note: Message Queuing (MSMQ) Activation will remain disabled because MSMQ is not available on Windows 11 for ARM64 client machines
Frequently Asked Questions (FAQs)
If I don’t upgrade to .NET Framework 4.8.1 will anything change for how I receive Windows or .NET Framework updates?
- No. Updates for previous versions of .NET Framework and for Windows operating systems components remain the same.
I am an IT Administrator managing updates for my organization, how do I ensure that my deployments include all existing versions of .NET Framework?
- As noted above, continue to rely on the same mechanisms for Windows and .NET Framework updates. Ensure that within your WSUS, SCCM or similar environment, you select updates that correspond to the “Windows” Product and continue to rely on the Classifications categories to select all applicable updates that align with your organization’s update criteria for Security and non-security content. This will ensure you continue to receive updates for all .NET Framework versions.
Does anything change about the way updates to .NET Framework 3.5 get delivered once I upgrade to .NET Framework 4.8.1?
- The .NET Framework 3.5 updates are included in the .NET Framework Cumulative Update and will not be affected by the upgrade to .NET Framework 4.8.1.
Please try out these improvements in the .NET Framework 4.8.1 and share your feedback in the comments below or via GitHub.
In the WCAG2.1 compliant accessible tooltips section, the first sentence in the second paragraph should say “… Windows Forms …” instead of ” … Widows Forms …”
Thanks Michael, I’ve corrected the typo.
Widows Forms loool 🙂 come on guys, my WinForm apps are not that old, project owners are still alive. 🙂
Did the system requirements change? In this blog post it lists Windows Server 2022 as the only supported server OS. But .NET 4.8 supports Windows Server 1803+, Server 2019 and Server 2022. Did a patch release of 4.8 just drop support for an entire family of server products?
.NET 4.8 also supports Windows 7 SP1, Windows 8.1. So looks like .NET 4.8.1 patch release also drops several client OS 🙁
.NET Framework 4.8.1 adds native support for customers building apps on, and for Arm64 devices, the support matrix for 4.8.1 on Arm64 reflects this and includes Windows 11 and later versions only.
.NET Framework 4.8.1 is also available on Windows 10 versions (20H2+) and Server 2022+ for x64 based devices. We realize that some customers need to stay on older OS versions for longer, so we plan to continue to support 4.8 on those OS versions for as long as the OS is in support. This means you can stay on 4.8 with the confidence that you will be fully supported with security, reliability, and compatibility fixes on 4.8 just like you would with 4.8.1.
I’m sorry but if 4.8.1 (a patch release) is dropping support for entire versions of OSes then Microsoft is violating the very principle of semantic versioning that they recommend everyone follows. Patch releases are for bug fixes and minor enhancements. No breaking changes should ever be in a patch release. Removing support for something violates that rule. So MS is not following the very principle they recommend to everyone else.
Furthermore Server 2019 is not an older OS version. It is fully supported until 9 Jan 2024 and then extended support until 2029. It is barely over the halfway point in its lifecycle. So saying that .NET 4.8.1 won’t support an OS that is middle age makes no sense to me.
If you have features that require OS-level support then do like you recommend everyone else do: check for OS support or break it into its own set of pieces that are independent of the core. This is going to cause so much confusion to people who, for security reasons, follow strict guidelines for upgrading to the latest patch of all software they run.
Same regarding client OS: Windows 7 SP1 with ESU is supported until 10 Jan 2023 (and there are definite signs that it will be extended until 10 Jan 2026), Windows 8.1 – until 10 Jan 2023, Windows 10 1607 – until 13 Oct 2026 and Windows 10 1809 – until 09 Jan 2029. So from the point of lifecycle they are not older OS version. And I totally agree with the last paragraph regarding the features that require support at the OS level.
.NET Framework doesn’t use semantic version. 4.8.1 isn’t a patch. It’s a feature update, like 4.5.1, 4.6.1 which added new features.
Patch updates are versioned separately.
This just means that 4.8.0 is where client side apps keep getting targeted at and 4.8.1 gets ignored… I still have some ltsc computers that are being targeted so 1607’s and 1809’s to support yet
What about LTSC versions 1607/1809? Why don’t they get the update? But if I only target 4.8 to let the applications run everywhere I will not get the fixes and if I target 4.8.1 I can’t run them on the LTSC versions. That makes no sense
Tara Overfield said above that We realize that some customers need to stay on older OS versions for longer, so we plan to continue to support 4.8 on those OS versions for as long as the OS is in support. This means you can stay on 4.8 with the confidence that you will be fully supported with security, reliability, and compatibility fixes on 4.8 just like you would with 4.8.1.
So you can safely stay on .NET 4.8 for broader reach.
If you drop support to Win7, YOU HAVE NO RIGHT to number version as 4.8.1 – it misleads people to think it’s “minor update”, while in reality it’s MAJOR BREAKING CHANGES.
You MS completely lost any conscience! You force people to move to your idiotic Win10! We don’t want to participate in your stupid experiments.
It might be a bit misleading, but it has happened before in .NET Framework history. For example, 4.6.1 dropped support for Vista.
But then, why are you forced to move to 4.8.1? Why can’t you just stay on 4.8?
That’s all very well, but Server 2019 is Windows 10, so supporting it on one and not the other is basically forcing us to upgrade our servers against our will. Since older server hardware doesn’t support Server 2022, you’re forcing a hardware upgrade as well, which is unacceptable given that the distinction between the two operating systems, and thus 4.8.1’s support of them, is entirely artificial.
So, if .Net 4.8.1 runs on Windows 10, why doesn’t it run on Windows Server 2019, which is effectively the same operating system? That’s not very good… it smacks of planned obsolescence and forcing organizations to upgrade against their will.
Windows Server 2019 is based on Windows 10 version 1809. The oldest supported client OS is Windows 10 version 20H2.
Since Windows Server 2019 doesn’t support ARM64 and is still receiving patches for .NET Framework, I cannot see the loss here really. Or do you desperately need accessible WinForms/WPF tooltips on your server OS?
I think there may be a targeting issue. If you distribute a .NET Framework app, you can either target 4.8 (no ARM64), 4.8.1 (no older Windows versions, including supported Windows versions) or try to build/distribute for both.
Targeting 4.8 will work, but no gain. Targeting 4.8.1 will probably lose more users on older Windows than ARM64 will gain (especially on servers). Targeting both could be a tooling mess, since the older csproj format didn’t have multiple targeting with TargetFrameworks tag, and I guess that if you’re stuck on .NET Framework than migrating csproj isn’t possible. So you’ll need to maintain two versions of the solution, each targeted for a different version?
You can convert .NET Framework projects to the SDK csproj format so multi-targeting is fully supported. This is a tooling chain feature unrelated to your actual targets. The only reason it hasn’t become the default is that you lose some features that older project s may rely on such as Nuget package transforms. I would like to think that almost all libraries multi-target now and even a lot of apps that either didn’t rely on transforms or understand the necessary changes.
But none of that really matters because you cannot really multi-target 4.8 and 4.8.1 anyway I don’t believe. Once the runtime is updated to 4.8.1 you’re running on that version whether you use its features or not. This is a framework installation issue, not a build issue as far as platform support goes.
I’m really curious what Visual Studio 2022 (the latest version) is going to do. Normally it provides workload updates to target newer framework versions. I’m sort of curious how it is going to behave if/when they add 4.8.1 to the list. You can install VS 2022 on machines that don’t support 4.8.1 and I think it ships with 4.8 already. I’ve always thought they ensure VS is built against the latest version of the framework when adding newer target packs but that wouldn’t be possible here unless they also drop support for OSes in VS 2022.
VS Installer for latest VS 2022 17.3.0 REL at least has separate checkboxes for .NET 4.8 SDK/Targeting pack and .NET 4.8.1 SDK/Targeting pack on the Separate Components tab. I’ve installed both and now I can choose between .NET 4.8 and .NET 4.8.1 in app creation dialog. Don’t know how it works under the hood but looks like it’s possible to have them both.
Note you don’t need to target 4.8.1 in order to support Windows ARM64. But on OSes older than Windows 11 22H2 (currently Insider Beta channel), you’ll need to build as ARM64 specifically since AnyCPU runs as x64 by default. (or I guess x86 on Windows 10)
(Yes, you don’t need to target 4.8.1 to add a ARM64 target either, VS allows this)
On Windows 11 22H2, you can use
to run an AnyCPU app as ARM64. I tried an .NET 4.5 app as ARM64 and it runs unchanged flawlessly.
This argument is documented in
but not in MS docs yet.
FYI: Tour of .NET Behavior on Windows 11 Arm64 -> https://github.com/dotnet/core/issues/7709
Perhaps I want to write tools which work on any machine I have. And while were at it, where’s my 20H2 patch for Windows Server 2019?
What will be the value in the registry to indicate this version installed?
Have same question. Docs for How to: Determine which .NET Framework versions are installed miss info about .NET 4.8.1. Also many people are curious how registry values look like when both .NET 4.8 SDK/Targeting pack and .NET 4.8.1 SDK/Targeting pack are installed (it is possible to check both checkboxes in VS Installer for latest VS 2022 17.3.0 REL – so one can choose between .NET 4.8 and .NET 4.8.1 in app creation dialog).
On Windows 11 v22H2: 533320
On all other supported Windows operating systems: 533325
I was looking for this two 🙂
The following page also need to be updated with the OSs that can install 4.8.1 separately:
Does .NET Framework 4.8.1 have msu version that can import into Windows Software Update Services (WSUS)，or can be dism integrated into install.wim?
You can extract KB5011048 cab file from the Offline installer (using 7-zip), it apply to all supported Windows OSs
Smart move based on data and usage patterns.
So .NET Core (now just .NET) is the successor that get’s all the news, so, unless there is a security bug fix concern that would affect legacy applications, why lose time releasing a new version for the old .NET Framework ?
This move make me makes me think most stayed on the old .NET Framework.
There are things that don’t make any sense and this on of them.
The reason is that a large part of existing business desktop applications run on net framework and their migration to net core is not realistic.
I completely agree with you….
The fact that I read earlier that Microsoft was going to upgrade the WebForms Visual Designer combined with this new version of the .NET Framework makes it appear that many developers and organizations are still working with the original frameworks and intend to stay with them.
For my won development, I have stayed with the 4.6 version of the .NET Framework as it has everything I need.
I never understood the move to .NET Core when Microsoft eliminated so much from the original framework that many people had come to rely on…
.NET Core (1.0 to 3.0) was not real framework for the nowadays demands and comparing with .NET Framework.
However starting from .NET Core 3.1/.NET 5.0, yes, .NET can replace .NET Framework for back-ends (webservices), APIs and Windows Services that don’t require UI, however if you have optimised code you will not see any real performance benefit comparing with .NET Framework.
The benefits are: to know that you have a supported framework that will have the news and updates; any future important demand security update and very important, compatibility with packages that starting to be designed only for .NET and not .NET Framework.
The prove that besides services, is not easy to port from .NET Framework to .NET is that Microsoft gave a step back and port Windows Forms. Seems to me that perhaps we will see the same for Web Forms (PS: I’m not a Web Forms developer so my opinion is not tied to it).
Microsoft have a very good framework (.NET) and my favority programming language (C#), however except on the dark ages with VB, microsoft always failed miserly with fron-ends: WebForms (deprecated): SilverLigth; Xamarin and now MAUI.
For front-ends I don’t trust Microsoft for long therm.
A company needs a tech that can trust for years or even decades and not just few months or few years.
It’s normal that a new tech must evolve and the old one start to cease support however Microsoft have a long history to be short on that (very short). Seems that they are behind the news released from others (Mobile it’s a good example). I recall when Microsoft was the leader, now it’s the follower.
I agree with you on many of your points.
However, I have worked with quite a lot in the original .NET Frameworks, including a lot of WebForms development. I have also tinkered with WCF, which I found rather easy to use compared to the projects did with the pure Remoting API. However, the feature I liked about remoting is that it a binary transfer protocol, which made it nearly impossible to breach. WCF has this as well, which if I go through with plans to build a client-server application based on my current, released application, I will probably use.
With .NET Core 5.0 and 6.0 now available I can see where Microsoft is starting to move their technologies and I can understand their reasons for doing so as .NET Core is being designed to be smaller and more modular.
However, throwing out WebForms and WCF was somewhat of a deal-breaker for me. To me, WebForms has always been the zenith of web development, which has been replaced with a a far more complex and fractured development environment with ASP.NET MVC and now ASP.NET Core. True, there have been issues with WebForms but I believe that over time all of them could have been resolved.
WebForms, in my view, has always been a superior environment as it forced development to be more modular and compartmentalized. But because many developers did not use this modularization properly they landed up complaining about WebForms’ poor performance and other issues, which I just saw as sour grapes.
A former Silicon Valley engineer who left the US to live in New Zealnd, and who I corresponded with for a short time, wrote a book that demonstrated how to make WebForms applications run like greased lightening. Aside from the proper development paradigms to be used, the book was mostly oriented towards the deployment and hardware configurations, which even today many organizations ignore.
ASP.NET MVC came into vogue because it was believed that high performance web applications could be developed simply base on quality source code. This was never true and hardware and network engineers in the 1990s new at this time the fallacy of relying simply on good source code to produce high performance applications.
In any event, it appears that Microsoft is slowly moving back to the WebForms model with recent updates with their Blazor Development Platform, which is what I l always suspected would happen.
Hopefully, they will return WebForms to .NET Core. When they do or another Open Source organization does then I will be happy… 🙂
Visual Studio wouldn’t have been ported to ARM64 without .NET Framework 4.8.1. Microsoft wants to migrate VS to .NET (Core) eventually but this will take years.
.NET Framework 4.8.1 was a low hanging fruit for faster results.
Why MS plays dirty tricks? Why this “minor update” is FOR WINDOWS 10 ONLY??? What the hell IMPORTANT you added to FW that it’s unable to work under Win7 ?
I have recently read that Microsoft was going to release an updated WebForms Visual Designer but I don’t see any reference to this with this announcement.
Is it still planned?
Does the “allos” in the “ndp481-x86-x64-allos-enu.exe” installer stand for ARM64?
Otherwise where is ARM64 offline installer?
No. “AllOS” stands for “all (supported) operating systems,” not “all platforms.” Currently, the supported operating systems are Windows 10 and 11, as well as Windows Server 2016, 2019, and 2022.
As its name suggests, “ndp481-x86-x64-allos-enu.exe” is for the x64 and IA-32 platforms only, not for ARM64.
ndp481-x86-x64-allos-enu.exe support arm64 too (the actual installer is update cab KB5011048 for all 3 architectures)
if you want the compressed cab files separately: