company_banner

.NET Core 3 для Windows Desktop

Автор оригинала: 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 бесплатных курсов для разработчиков
Microsoft
373,10
Microsoft — мировой лидер в области ПО и ИТ-услуг
Поделиться публикацией

Похожие публикации

Комментарии 13

    +1
    Судя по названию кроссплатформенность не завезли.
      +1
      Кроссплатформенность завезли, но без формочек на линуксе. Если вам нужен именно GUI на Linux, то есть Avalonia UI Framework.
        0
        Про кроссплатформенность .NET Core я в курсе, интересно WPF.
      +1
      Список преимуществ перехода на .net core выглядит бедновато, из существенного разве что — билд в единый файл (чтобы приложение не требовало устанавки .net framework) так что пожалуй есть какой-то смысл начинать писать новое приложение под .net core, но нет особого смысла мигрировать старое
        0
        Насколько я понимаю, в .net библиотеки общие на все приложения в большинстве сценариев. Это может быть недостатком: если Ваше приложение нацелено только на одну версию, на клиенте придется развернуть эту версию .net полностью, хотя, возможно, большинство библиотек из неё не понадобится. Вдобавок, нет гарантии что Ваше приложение будет использовать ту же самую библиотеку весь жизненный цикл.
        На .Net Core есть выбор: можно сделать билд, нацеленный на конкретный набор библиотек, без лишнего. Важно, что этот набор библиотек поставляется вместе с основным приложением и не пересекается с библиотеками, используемыми соседним приложением. Это вроде как способствует стабильности в дальнейшей эксплуатации, ценой большего объема, занимаемого файловой системой.
          0

          Если ваше старое приложение не развивается (нет новых фич) и вы его только поддерживаете (правите баги), то мигрировать не смысла.
          Однако если вы пилите новые фичи, то есть смысл в переходе. Просто потому, что сторонние библиотеки потихоньку перестают поддерживать "старое" и если без них никак, то Вы тоже должны идти к "новому".

            0

            если я не ошибаюсь, фреймворк всё же нужен, хоть какой-то, даже 2. Иначе пишет, что-то типо "неверный формат приложения". Пробовал как-то запускать на голой win7 без сервис пака. Собственно, все надежды этой автономности были на улучшенную совместимость со старыми виндами, которые десятилетиями не обновлялись, а тут вдруг надо взять и срочно что-то запустить. Но походу не судьба ((

            0

            Что с WinForms или WPF на других платформах? К примеру, есть у меня утилита, которая работает на Windows и Mono x86 на MacOS. С выходом Catalina, уже ее нормально не запустить, а WinForms в Mono x64 не планируется. Даст ли что-то миграция на Net Core 3? Если нет, то какие вообще варианты остаются для кросплатформенных GUI утилит?

              0
              Avalonia
                0

                Web. Возможно self-hosted, но web.

                  0
                  Не подскажете — а есть визуальный дизайнер формочек для веба/netcore, что бы не отвлекаться на написание html/js, а быстренько набросать форму, типа [поле][поле][кнопка]?
                  0
                  Xamarin, конечно же
                    +1
                    На Xamarin можно делать GUI под Linux? Если да, то можно ссылку на пример/статью? Если я правильно понимаю, там используется GTK и mono, о net.core речи не идет. Плюс создавать такие приложения можно только по Windows, Xamarin.Forms UI designer под Linux не работает. Если не прав, поправьте, пожалуйста.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое