Sergey Lutay's Blog

Read this article in your language IT | EN | DE | ES

Предисловие

В сентябре Microsoft выпустили .NET Core поддерживающий создание настольных приложений Windows, включая WPF и Windows Forms. Мы счастливы наблюдать, за тем как многие разработчики делятся своими историями о переносе настольных приложений (и управляющих библиотек) в .NET Core. Комания постоянно слышит истории о том, что разработчики настольных систем на платформе .NET Windows поддерживают свой бизнес с помощью WPF и Windows Forms, особенно в тех случаях, когда настольные системы превосходны, включая

- UI-dense формы над данными приложений (FOD) 

- Оперативный интерфейс пользователя

- Приложения, которые могут работать в режиме оффлайн или быть выключены

- Устройства с приложениями, которые привязаны к драйверам пользователей

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

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

.NET Core (и в будущем .NET 5, построенный на ведущих основах .NET Core) станет будущим .NET. Мы стремимся поддерживать .NET Framework долгие годы, однако он не будет получать никаких новых функций, мы их добавим только в .NET Core (в перспективе .NET 5). Чтобы улучшить стеки рабочих столов Windows и позволить разработчикам настольных компьютеров .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, как показано в примере ниже.

Различия между рабочим столом .NET Framework и рабочим столом .NET Core

При разработке настольных приложений вы не заметите большой разницы между версиями 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 или более поздней версией. Не забудьте установить флажок в меню Сервис-> Параметры-> Функции предварительного просмотра-> Использовать дизайнер предварительного просмотра Windows Forms для приложений .NET Core и перезапустить 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. вместо файла machine.config использует файл <something>.runtimeconfig.json,который поставляется вместе с приложением и имеет ту же общую цель и аналогичную информацию. Некоторые конфигурации, такие как system.diagnostics, system.net или system.servicemodel, не поддерживаются, поэтому файл конфигурации приложения не удастся загрузить, если он содержит какой-либо из этих разделов. Это изменение касается сценариев трассировки System.Diagnostics и клиентов WCF, которые обычно настраивались с использованием конфигурации XML ранее. В .NET Core вам нужно вместо этого настроить их в коде. Чтобы изменить поведение без перекомпиляции, рассмотрите возможность настройки типов трассировки и WCF, используя значения, загруженные из источника Microsoft.Extensions.Configuration или из appSettings. 

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

Начало работы

Проверьте эти короткие видеоуроки:

- Начало работы с WPF на .NET Core

- Начало работы с Windows Forms в .NET Core

- Различия между .NET Core и .Net Framework, что выбрать для вашего приложения

Перенесение приложений с .NET Framework на .NET Core

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

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

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

Инструмент - try-convert.  попытается перенести файлы проекта старого стиля в новый SDK-стиль и перенастроить соответствующие проекты в .NET Core.

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

<TargetFramework>netstandard2.1</TargetFramework>

так что их могут использовать абоненты, ориентированные на множество различных платформ .NET. С другой стороны, если библиотека использует функцию, для которой требуется .NET Core (например, Windows desktop UI APIs), библиотека может ориентироваться на .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 не работает, вот материалы о том, как переносить ваше приложение вручную.

Видео

- Пример простого переноса

- Пример расширенного переноса

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

- Пример простого переноса

- Пример расширенного переноса (часть 1, часть 2)

- Обзор процесса переноса

Источник