Как стать автором
Обновить
0
Microsoft
Microsoft — мировой лидер в области ПО и ИТ-услуг

.NET Core 3 для Windows Desktop

Время на прочтение6 мин
Количество просмотров21K
Автор оригинала: Microsoft
В сентябре мы выпустили поддержку .NET Core для создания настольных приложений Windows, включая WPF и Windows Forms. С тех пор мы были рады видеть, что многие разработчики делятся своими историями о переносе настольных приложений в .NET Core. Мы постоянно слышим от .NET-разработчиков настольных приложений для Windows истории о том, как они поддерживают свой бизнес с помощью WPF и Windows Forms, особенно в тех случаях, когда десктоп выигрывает, включая:

  • FOD-приложения (forms over data) с плотным UI
  • Отзывчивый пользовательский интерфейс с низкой задержкой
  • Приложения, которые должны работать в автономном режиме
  • Приложения с зависимостями от кастомных драйверов устройств

Заглядывайте под кат, чтобы узнать больше о преимуществах .NET Core для создания приложений Windows.



Почему Windows desktop на .NET Core?


.NET Core (и в будущем .NET 5, построенный на основе .NET Core) станет будущим .NET. Мы стремимся поддерживать .NET Framework как можно дольше, однако она не будет получать никаких новых функций, они будут добавлены только в .NET Core (и, в конечном итоге, .NET 5). Чтобы улучшить стеки Windows desktop и позволить разработчикам настольных приложений .NET получать выгоду от всех обновлений будущего, мы представили Windows Forms и WPF для .NET Core. Они по-прежнему останутся технологиями, предназначенными только для Windows, поскольку они тесно связаны с API-интерфейсами Windows. Но .NET Core, помимо кроссплатформенности, имеет множество других функций, которые могут улучшить настольные приложения.

Прежде всего, все улучшения среды выполнения и языковые функции будут добавлены только в .NET Core, а в будущем — в .NET 5. Хорошим примером здесь является C# 8, который стал доступен в .NET Core 3.0. Кроме того, .NET Core версии Windows Forms и WPF станут частью платформы .NET 5. И, портируя ваше приложение на .NET Core, вы готовите его к .NET 5.

Кроме того, .NET Core обеспечивает гибкость развертывания для ваших приложений благодаря новым параметрам, недоступным в .NET Framework, таким как:

  • Параллельное развертывание. Теперь у вас может быть несколько версий .NET Core на одном компьютере и вы можете выбрать, на какую версию должно ориентироваться каждое из ваших приложений.
  • Автономное развертывание. Вы можете развернуть платформу .NET Core вместе со своими приложениями и стать полностью независимым от среды конечных пользователей — в вашем приложении есть все, что нужно для запуска на любом компьютере с Windows.
  • Меньшие размеры приложения. В .NET Core 3 мы представили новую функцию под названием компоновщик (также иногда называемую триммером), которая будет анализировать ваш код и включать в автономное развертывание только те сборки из .NET Core, которые необходимы для вашего приложения. Таким образом, все детали платформы, которые не используются в вашем случае, будут удалены.
  • Единые .exe файлы. Вы можете упаковать свое приложение и платформу .NET Core в один файл .exe.
  • Улучшена производительность среды выполнения. .NET Core имеет много оптимизаций производительности по сравнению с .NET Framework. Если вспомнить об истории .NET Core, изначально созданной для рабочих нагрузок на веб и сервер, это помогает понять, может ли ваше приложение ощутить заметные преимущества от оптимизации рантайма. В частности, настольные приложения с сильной зависимостью от операций ввода-вывода файлов, работы в сети и работы с базами данных, скорее всего, покажут улучшения производительности для этих сценариев. Некоторые области, в которых вы можете не заметить значительных изменений, касаются производительности рендеринга пользовательского интерфейса или запуска приложений.

Установив свойства <PublishSingleFile><RuntimeIdentifier> и <PublishTrimmed> в профиле публикации, вы сможете развернуть обрезанное автономное приложение в виде одного файла .exe, как показано в примере ниже.

<PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <PublishSingleFile>true</PublishSingleFile>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

Различия между .NET Framework desktop and .NET Core desktop


При разработке настольных приложений вы не заметите большой разницы между версиями WPF и Windows Forms для .NET Framework и .NET Core. Часть наших усилий заключалась в том, чтобы обеспечить функциональную схожесть между этими платформами в области настольных ПК и расширить возможности .NET Core в будущем.

Приложения WPF полностью поддерживаются в .NET Core, и вы можете начать работу с ними, пока мы работаем над незначительными обновлениями и улучшениями. Для Windows Forms среда выполнения полностью перенесена в .NET Core, и сейчас команда работает над конструктором Windows Forms Designer. Мы планируем подготовить его к четвертому кварталу 2020 года, а пока вы можете проверить предварительную версию конструктора в Visual Studio 16.4 Preview 3 или более поздней. Не забудьте установить флажок в меню Tools->Options->Preview Features->Use the Preview of Windows Forms designer for .NET Core apps и перезапустить Visual Studio. Пожалуйста, имейте в виду, что опыт использования пока ограничен, так как работа еще ведется.

Важные изменения


В .NET Framework и .NET Core произошли несколько серьезных изменений, но большая часть кода, связанного с областями Windows Forms и WPF, была перенесена в Core в том же виде. Если вы ранее использовали такие компоненты, как WCF Client, Code Access Security, App Domains, Interop и Remoting, вам потребуется отрефакторить код, если вы хотите переключиться на .NET Core.

Следует помнить еще одну вещь: пути вывода по умолчанию в .NET Core отличаются от путей в .NET Framework, поэтому, если в вашем коде есть некоторые допущения относительно структуры файлов/папок запущенного приложения, то, вероятно, оно упадет в рантайме.

Также есть изменения в настройке функций .NET. .NET Core вместо файла machine.config использует файл <something>.runtimeconfig.json, который поставляется вместе с приложением и имеет ту же основную цель и аналогичную информацию. Некоторые конфигурации, такие как system.diagnosticssystem.net, или system.servicemodel, не поддерживаются, поэтому файл конфигурации приложения не удастся загрузить, если он содержит какой-либо из этих разделов. Это изменение касается трассировки System.Diagnostics и клиентских WCF сценариев, которые ранее обычно настраивались с использованием конфигурации XML. В .NET Core вам нужно вместо этого настроить их в коде. Чтобы изменить поведение без перекомпиляции, рассмотрите возможность настройки типов трассировки и WCF, используя значения, загруженные из источника Microsoft.Extensions.Configuration или из appSettings.

Вы можете найти больше информации о различиях между .NET Core и .NET Framework в документации.

Чтобы начать работу


Посмотрите эти короткие туториалы:


Портирование с .NET Framework на .NET Core


Прежде всего, запустите Portability Analyzer (анализатор переносимости) и при необходимости обновите код, чтобы обеспечить 100% совместимость с .NET Core. Вот инструкции по использованию анализатора переносимости.. Мы рекомендуем использовать управление исходным кодом или сделать резервную копию вашего кода, прежде чем вносить какие-либо изменения в свое приложение, на тот случай, если рефакторинг не пройдет так, как вы хотите, и вы решите вернуться к своему исходному состоянию.

Когда ваше приложение будет полностью совместимо с .NET Core, вы будете готовы его портировать. В качестве отправной точки вы можете попробовать инструмент, который мы создали, чтобы помочь автоматизировать преобразование ваших проектов .NET Framework в .NET Core – try-convert.

Важно помнить, что этот инструмент является лишь отправной точкой в ​​вашем пути к .NET Core. Также это не поддерживаемый продукт Microsoft. Хотя он может помочь вам с некоторыми из механических аспектов миграции, он не будет обрабатывать все сценарии или типы проектов. Если в вашем решении есть проекты, которые инструмент отклоняет или не может преобразовать, вам придется переносить их вручную. Не беспокойтесь, мы подготовили много уроков о том, как это сделать (в конце статьи).

Инструмент try-convert попытается перенести файлы проекта старого стиля в новый SDK-стиль и перенастроить соответствующие проекты в .NET Core. Для ваших библиотек мы оставляем на ваше усмотрение выбор платформы: .NET Core или .NET Standard. Вы можете указать одну из них в файле проекта, обновив значение для <TargetFramework>. Библиотеки без зависимостей, специфичных для .NET Core, таких как WPF или Windows Forms, могут выиграть от выбора .NET Standard:

<TargetFramework>netstandard2.1</TargetFramework>

так что они могут использоваться вызывающими объектами, ориентированными на множество различных платформ .NET. С другой стороны, если библиотека использует функцию, для которой требуется .NET Core (например, Windows desktop UI API), библиотеке стоит ориентироваться на .NET Core:

<TargetFramework>netcoreapp3.0</TargetFramework>

try-convert — это глобальный инструмент, который вы можете установить на свой компьютер, и затем вызвать из CLI:

C:\> try-convert -p <path to your project>

или

C:\> try-convert -w <path to your solution>

Как упоминалось ранее, если инструмент try-convert не работает в вашем случае, вот материалы о том, как переносить приложение вручную.

Видео


Документация




Читайте также: 7 бесплатных курсов для разработчиков
Теги:
Хабы:
Всего голосов 10: ↑10 и ↓0+10
Комментарии13

Публикации

Информация

Сайт
www.microsoft.com
Дата регистрации
Дата основания
Численность
Неизвестно
Местоположение
США

Истории