Представляем .NET 5.0 Preview 6

На прошлой неделе мы выпустили .NET 5.0 Preview 6. Версия содержит небольшой набор новых функций и улучшений производительности. Пост .NET 5.0 Preview 4 посвящен тому, что мы планируем выпустить в .NET 5.0. Большинство функций в настоящее время уже реализовано, но некоторые еще не в своем окончательном состоянии. Мы ожидаем, что релиз будет полнофункциональным с Preview 8.

Вы можете скачать .NET 5.0 Preview 6, для Windows, macOS и Linux:

• Установщики Windows и macOS
• Полный список
• Образы Docker
• Snap-установщик

ASP.NET Core и EF Core также были выпущены на прошлой неделе. Примечание: EF Core 5.0 не будет поддерживать .NET Standard 2.0 или .NET Framework. Читайте пост о выпуске EF Core чтобы узнать больше.

Вам нужно использовать Visual Studio 2019 16.7 для работы с .NET 5.0. .NET 5.0 теперь поддерживается в Visual Studio for Mac. Установите последнюю версию расширения C# для использования .NET 5.0 с Visual Studio Code.

Заметки:

• .NET 5.0 — заметки о версии
• .NET 5.0 — известные проблемы
• Выпуск на GitHub
• Трекер проблем на GitHub

Обновление Windows ARM64

Мы анонсировали поддержку Windows ARM64 в рамках Preview 4. В то время мы включали только консольные приложения и приложения ASP.NET Core в Windows ARM64. SDK Preview 6 теперь включает поддержку Windows Forms. Это означает, что вы можете создавать и запускать приложения Windows Forms на устройствах Windows ARM64, так же, как на x64. Мы все еще работаем над добавлением поддержки WPF в Windows ARM64.

Вы можете увидеть пример приложения Windows Forms, работающего на ноутбуке ARM64, как показано ниже.



В Visual Studio 16.7 ожидается поддержка удаленного отладчика Visual Studio .NET для Windows ARM64. Мы ожидаем, что вскоре после этого появится поддержка удаленного отладчика Visual Studio Code .NET. Чтобы избежать путаницы, эта поддержка относится к работе Visual Studio или Visual Studio Code на компьютере x64 и удаленному подключению к работающему приложению .NET на компьютере Windows ARM64. Кроме того, Visual Studio Code добавляет поддержку ARM64. Мы добавим поддержку расширения C# и отладчика .NET, работающих в версии Visual Studio Code для Windows ARM64, однако даты пока неизвестны.

Windows Forms

Пользователи Visual Basic привыкли делать так, чтобы их приложения были single-instanced (один экземпляр запускался за раз). Это поведение теперь доступно через WindowsFormsApplicationBase.IsSingleInstance. Вот отличное объяснение этого поведения от Скотта Хансельмана.

Команда добавила поддержку свертывания в ListViewGroup. Это изменение облегчает управление формой с несколькими ListViewGroups.

А вот и результат:

Улучшение качества кода RyuJIT

Команда RyuJIT продолжает вносить действительно важные улучшения, превью за превью. Они не разочаровали и в Preview 6. Давайте посмотрим:

• Основные улучшения
  
  • Улучшения Struct
    
  • Оптимизация для удаления избыточных нулевых инициализаций
• Ход реализации аппаратных встроенных функций ARM64
  
  • Реализация Duplicate и DuplicateSelectedScalar
  • ASIMD Shift Intrinsics
  • Polynomial Multiply Long Intrinsics
  • Оптимизация методов Vector64 и Vector128.Create
  • Оптимизация ToScalar() и GetElement() для использования интринсиков arm64
  • Оптимизация ToVector128, ToVector128Unsafe и Vector128.GetLower()
• Улучшения в сгенерированном коде ARM64: значительно уменьшен размер кода ARM64
  
  • Оптимизация непрямых вызовов для сценариев R2R, Arm и Arm64
  • Оптимизация virtual call stub для R2R и JIT
  
  

Однофайловые приложения

Мы продолжаем улучшать поддержку однофайловых приложений в .NET 5. Наша цель — упростить публикацию приложения в виде одного файла для Windows, macOS и Linux. Мы уже близки. Когда мы в последний раз говорили об этом, в Preview 4, я упоминал, что приложениям «одного файла» Windows требуется несколько дополнительных runtime-файлов. Мы добавили новую опцию для включения собственных двоичных файлов и любого дополнительного содержимого (например, изображений) в один файл. Эти файлы будут извлечены при первом запуске. Приложения, предназначенные для Linux и macOS, не должны использовать эту опцию для собственных двоичных файлов среды выполнения, если только они не хотят использовать ее для мультимедиа или другого контента.

Текущие ограничения:

• В Linux единый файл с подключенными runtime-компонентами все еще должен существовать. Поэтому собственные двоичные файлы среды выполнения будут публиковаться в виде отдельных файлов (аналогично интерфейсу Windows).
• В Linux готовые к запуску сборки, встроенные в пакет, загружаются как сборки IL.

Нативно-размещенное приложение

За прошедшие годы мы увидели множество моделей хостинга для .NET в нативных приложениях. @rseanhall предложил и реализовал новую новую модель для этого, которая использует все встроенные функциональные возможности приложения, предоставляемые уровнем размещения приложений .NET (в частности, загрузкой зависимостей), в то же время позволяя вызывать пользовательскую точку входа из собственного кода. Это идеально подходит для многих сценариев, и понятно, что это становится популярным методом среди разработчиков, которые размещают компоненты .NET из нативных приложений.

Два основных PR:

• Включить вызов get_runtime_delegate из контекста приложения
• Реализация hdt_get_function_pointer

Поддержка платформ

Мы обновили нашу страницу .NET 5 — Поддерживаемые версии ОС, чтобы отразить наши последние планы по поддержке платформы .NET 5.0. Пожалуйста, расскажите нам, что вы думаете. Чего нам не хватает?

Мы знаем, что менеджер пакетов и поддержка контейнеров, которые мы предлагаем, не указаны на этой странице. Это должно быть исправлено. Мы планируем добавить эту информацию до выпуска .NET 5.0.