While most of the attention is on .NET Core, work continues on the classic .NET Framework. An "early access” preview of .NET 4.8 shows the areas that Microsoft is most concerned about including high graphics Dots per Inch (DPI), accessibility, and concurrency.
.NET 4.8 is expected to be released in 2019. The current expectation is that it will run on Windows 10 build 1607 at later, but that decision isn't final.
Before we get into what is included, it should be noted that the most requested feature, Span<T>, is not going to be part of this release. According to Rich Lander of Microsoft,
Span is included in .NET Core 2.1. We explored including Span in .NET Framework 4.8 and decided against it due to compatibility concerns for existing applications. You can get access to Span and additional related types in the System.Memory Nuget package which enables some of the scenarios that are enabled on .NET Core.
High DPI continues to be a focus for .NET. As monitor resolutions continue to improve, applications need to be scaled up to compensate lest the text and images are too small to be legible. In this release, ClickOnce and WinForms are receiving high DPI updates.
There are a couple reasons why high DPI issues keep occurring. First is the availability of high resolution monitors. Microsoft couldn't effectively test scaling at 200 and 300% until hardware that needed that amount of scaling became available. So until monitors stop improving, scaling will continue to be a problem.
Another challenge is multi-monitor setups. When an application moves between monitors with different resolutions, the scaling has to be recalculated and images swapped out. Even worse, an application can overlap two or more monitors with different resolutions. Various compromises are necessary to address this situation and the results aren't always satisfying.
In addition to the usually internal tweaking such as reducing memory usage for AsyncLocal or fine-tuning spin locks, this release fixes an issue where SqlDataReader.ReadAsync wasn't actually being performed asynchronously.
Deadlocks and Race Conditions
Given the maturity of the .NET Framework, it may come as a surprise to learn that many of the core libraries still harbor race conditions and dead locks. Here is a partial list of concurrency-related issues.
- CLR: potential crash with concurrent calls to a new dynamic method
- CLR: possible deadlock when calling Dispose() on an EventSource
- Networking: NetworkInformation.NetworkChange deadlock scenario when there is a lock around NetworkChanged listener and user's callback
- WCF: race-condition that exists in AsyncResult that closes a WaitHandle before Set() is called
- WCF: race-condition when aborting connections which caused ObjectDisposedException to be thrown in CleanupChannelCollections
- Workflow: under extreme usage conditions (high volume of connections to MSDTC), it was possible for a CriticalSection to be held by a single thread indefinitely
- User Interface Accessibility (UIA)
UIA concerns continue to be a priority with WinForms gaining new UIA behaviors and UIA bugs being fixed in both it and WPF. (Many non-UIA bugs were also fixed in both.)