Announcing .NET Framework 4.8.1

Tara Overfield

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:

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!

48 comments

Discussion is closed. Login to edit/delete existing comments.

  • David Greenwell 0

    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?

  • Jim Foye 0

    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?

  • Yuanheng YangMicrosoft employee 0

    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. ” (Elapsed time: 0 00:02:04).

    Any suggestions on that?

    • abbodi86 assi 0

      Use the Offline installer
      the redir links for downloading the KB5011048 cab files are not working (active) in the web installer

  • John 0

    Nah, I will stay on .NET 4.8 with older Windows support. Long live 4.8!

  • Arthur Haag 0

    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 tooltip prevents this from happening. This is reproducible and did not happen before 4.8.1.

    Unexpected Exception

    Invalid window handle

    Exception chain:

    Win32Exception

    ======================================================================

    Details

    Win32Exception

    Message:

    Invalid window handle

    Stack trace:

    at MS.Internal.PointUtil.ScreenToClient(Point pointScreen, PresentationSource presentationSource)
    at System.Windows.Controls.PopupControlService.ConvexHull.ContainsMousePoint()
    at System.Windows.Controls.PopupControlService.MouseHasLeftSafeArea()
    at System.Windows.Controls.PopupControlService.OnMouseMove(IInputElement directlyOver)
    at System.Windows.Controls.PopupControlService.OnPostProcessInput(Object sender, ProcessInputEventArgs e)
    at System.Windows.Input.InputManager.RaiseProcessInputEventHandlers(ProcessInputEventHandler postProcessInput, ProcessInputEventArgs processInputEventArgs)
    at System.Windows.Input.InputManager.ProcessStagingArea()
    at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
    at System.Windows.Input.MouseDevice.Synchronize()
    at System.Windows.Input.MouseDevice.PostProcessInput(Object sender, ProcessInputEventArgs e)
    at System.Windows.Input.InputManager.RaiseProcessInputEventHandlers(ProcessInputEventHandler postProcessInput, ProcessInputEventArgs processInputEventArgs)
    at System.Windows.Input.InputManager.ProcessStagingArea()
    at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
    at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
    at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
    at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
    at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
    at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
    at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
    at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
    at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
    at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
    at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
    at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
    at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
    at System.Windows.Application.RunDispatcher(Object ignore)
    at System.Windows.Application.RunInternal(Window window)
    at Ade.Application.ApplicationStarter.Run()
    at (String[] )
    at PCWorxNext.Startup.Main(String[] args)

  • Duncan Heathfield 0

    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.

Feedback usabilla icon