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.
Known issues
| 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.
Thank you!
We have noticed that this update has been installed on some end-user machines as KB5011048.
It breaks some .NET DLLs which were obfuscated using SecureTeam Agile.NET version 6.4.0.23. These components stop working properly with FW 4.8.1.
Removing the update and restoring 4.8.0 makes things work again.
Re-obfuscating these DLLs with the latest Agile.NET release (6.4.0.42) seems to make them compatible with FW 4.8.1.
Hello, we've got a problem with tooltips after switching to 4.8.1. We have an IntelliSense like completion popup, where we display tooltips on the completion items. This popup is opened/closed with a high frequency during UI automation tests. The mouse rests at the same position on screen, so that the tooltip is shown for the completion under the mouse, when the completion popup is opened. Sometimes a crash occures with the following callstack. Deactivating the...
Nah, I will stay on .NET 4.8 with older Windows support. Long live 4.8!
I failed to install .net 4.8.1 via web installer , got below error:
E:\d6d2161d66040a2abbfd8bfd4473b7\TMP2C8A.tmp - Signature verification for file Windows10.0-KB5011048-x64.cab (E:\d6d2161d66040a2abbfd8bfd4473b7\TMP2C8A.tmp) failed with error 0x800b0003 (The form specified for the subject is not one supported or known by the specified trust provider.)
No FileHash provided. Cannot perform FileHash verification for Windows10.0-KB5011048-x64.cab
Final Result: Installation failed with error code: (0x800B0003), "The form specified for the subject is not one supported or known by the specified trust provider. "...
Use the Offline installer
the redir links for downloading the KB5011048 cab files are not working (active) in the web installer
So I’ll upgrade to this minor update, lose support for some platforms, and users will be able to clear tooltips easier. Am I missing something?
While attempting to install 4.8.1 on Surface Pro ARM architecture I get the following
.NET Framework 4.8.1 has not been installed because:
The form specified for the subject is not one supported or known by the specified trust provider.
For more information about this problem see the
Any suggestions on that?
Does the “allos” in the “ndp481-x86-x64-allos-enu.exe” installer stand for ARM64?
Otherwise where is ARM64 offline installer?
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:
x86: http://go.microsoft.com/fwlink/?LinkID=2203225
x64: http://go.microsoft.com/fwlink/?LinkID=2203406
amr64: http://go.microsoft.com/fwlink/?LinkID=2203407
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.
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?
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 ?
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.
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.
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 (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...
Hugo...
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...
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.