Хотя основное внимание уделяется .NET Core, продолжается работа и над классической платформой .NET Framework. Предварительный просмотр «раннего доступа» .NET 4.8 демонстрирует области, в которых Microsoft больше всего озабочена включением высоких графических точек на дюйм (DPI), доступности и параллелизма.

Ожидается, что .NET 4.8 будет выпущен в 2019 году. Ожидается, что он будет запущен позже, на Windows 10 сборки 1607, но это решение не является окончательным.

Span<T>

Прежде чем мы рассмотрим то, что включено, следует отметить, что самая запрошенная функция Span <T> не будет частью этой версии. По словам Ричарда Ландера из Microsoft,

Span включен в .NET Core 2.1. Мы провели исследования, в том числе в отношении Span, в .NET Framework 4.8 и решили отказаться от него из-за проблем совместимости для существующих приложений. Вы можете получить доступ к Span и дополнительным связанным типам в пакете System.Memory Nuget, который позволяет использовать некоторые из сценариев, включенных в .NET Core.

System.Memory: https://www.nuget.org/packages/System.Memory/

Высокий DPI

Высокий уровень DPI продолжает оставаться  в центре внимания для .NET. Поскольку разрешения монитора продолжают улучшаться, приложения необходимо масштабировать, чтобы компенсировать тот факт, что текст и изображения слишком малы, чтобы быть четкими. В этом выпуске ClickOnce и WinForms получают большие обновления DPI.

Есть несколько причин, по которым возникают высокие проблемы с DPI. Во-первых, это наличие мониторов с высоким разрешением. Microsoft не смогла эффективно протестировать масштабирование на 200 и 300%, пока аппаратное обеспечение, требующее такого объема масштабирования, не стало доступно. Поэтому, пока мониторы не перестанут улучшаться, масштабирование будет оставаться проблемой.

Другая проблема заключается в настройках нескольких мониторов. Когда приложение перемещается между мониторами с различными разрешениями, масштабирование должно быть пересчитано, а изображения выгружены. Хуже того, приложение может перекрывать два или более монитора с разными разрешениями. Для устранения этой ситуации необходимы различные компромиссы, и результаты не всегда удовлетворяют.

Производительность

В дополнение к обычно внутренней настройке, такой как сокращение использования памяти для AsyncLocal или тонкой настройки активных блокировок, этот выпуск устраняет проблему, где SqlDataReader.ReadAsync фактически не выполнялся асинхронно.

Взаимная блокировка и состояние гонки

Учитывая зрелость .NET Framework, может показаться неожиданным узнать, что многие из основных библиотек по-прежнему поддерживают состояние гонки и мертвые блокировки. Ниже приведен неполный список проблем, связанных с параллелизмом.

• CLR: потенциальный сбой при одновременном вызове нового динамического метода
• CLR: возможная взаимная блокировка при вызове Dispose () на EventSource
• Networking: NetworkInformation.NetworkChange сценарий блокировки, когда есть блокировка при прослушивании NetworkChanged и обратном вызове пользователя
• WCF: состояние гонки, существующее в AsyncResult, которое закрывает WaitHandle перед вызовом Set ()
• WCF: состояние гонки при прерывании соединений, вызвавших исключение ObjectDisposedException в CleanupChannelCollections
• Рабочий процесс: при экстремальных условиях использования (большой объем соединений с MSDTC), возможно, что CriticalSection удерживается одним потоком на неопределенный срок
• Доступность пользовательского интерфейса (UIA)

Проблемы с UIA по-прежнему остаются приоритетом, когда WinFormsприобретает новые модели поведения в UIA, а ошибки UIA фиксируются как в нем, так и в WPF. (Многие ошибки, не связанные с UIA, также были исправлены в обоих.)

No Comments