Sergey Lutay's Blog

В Windows 10 версии 2004 представлено концепцию размещенных приложений в Windows App Model. Размещенные приложения регистрируются как независимые приложения в Windows, но для их запуска требуется хост-процесс. Примером может служить файл сценария, который требует установки его хоста (например, Powershell или Python). Сам по себе это всего лишь файл, и он не имеет возможности отображаться как приложение для Windows. С помощью модели размещенного приложения приложение может объявить себя хостом, а затем пакеты могут объявить зависимость от этого хоста и называться размещенными приложениями. Когда запускается размещенное приложение, исполняемый файл узла запускается с идентификатором пакета размещенного приложения, а не с его собственной идентификацией. Это позволяет хосту иметь доступ к содержимому пакета размещенного приложения, а при вызове API он делает это с помощью идентификатора размещенного приложения.

Предыстория

Современные приложения определяются для Windows через подписанные пакеты MSIX. Пакет обеспечивает идентификацию, поэтому он известен системе и содержит все файлы, активы и регистрационную информацию для приложения. У многих приложений есть сценарии, в которых они хотят разместить контент и двоичные файлы, такие как точки расширения, из других приложений. Существуют также сценарии, в которых хост-приложение представляет собой скорее механизм времени выполнения, который загружает содержимое сценария. Вдобавок ко всему, существует желание, чтобы эти размещенные приложения выглядели и вели себя как отдельное приложение в системе – где у него есть собственная стартовая плитка, идентификация и глубокая интеграция с такими функциями Windows, как BackgroundTasks, Notifications и Share. С помощью модели размещенного приложения можно легко переименовать приложение розничного киоска, или скрипт Python или Powershell теперь можно рассматривать как отдельное приложение.

Разработчики пытаются сделать это сегодня одним из двух способов. Во-первых, они просто используют ярлык на рабочем столе для запуска хоста. Но как показывает опыт, это не имеет какой-либо глубокой интеграции с Windows и оболочкой, поскольку «приложение» – это исполняемый файл узла, а не сценарий. Чтобы получить более глубокую интеграцию, разработчики могут создать упакованное приложение, включающее двоичные файлы хоста в пакете. Хотя пакет теперь будет отдельным приложением и будет иметь возможность глубокой интеграции с Windows, этот подход неэффективен, поскольку каждое приложение должно было бы перераспределять хост а это может повлечь за собой потенциальные проблемы с обслуживанием и лицензированием.

Модель размещенных приложений удовлетворяет потребности этих размещенных приложений. Это зависит от двух частей: «хоста», доступного для других приложений, и «размещенного приложения», которое указывает на  зависимость от хоста. Когда запускается размещаемое приложение, в результате хост запускается под идентификатором пакета размещенного приложения, так что он может загружать визуальные ресурсы, содержимое из местоположения пакета размещенного приложения, и когда он вызывает API, он делает это с идентификатором, объявленным в размещенном приложении. Размещенное приложение получает пересечение возможностей, объявленных между хостом и размещенным приложением – это означает, что, если размещенное приложение не может запросить больше возможностей, чем предоставляет хост. В этом первоначальном выпуске модели размещенных приложений поддерживаются упакованные настольные приложения, и Windows будет расширять поддержку узлов UWP в будущих выпусках.

Что такое хост и размещенное приложение?

В частности, Host – это исполняемый файл в пакете, объявленном расширением HostRuntime который указывает на основной исполняемый файл или процесс выполнения для размещенного приложения. Расширение HostRuntime имеет атрибут Id, и этот идентификатор упоминается в качестве зависимости размещенным приложением в манифесте пакета. Хост может определить идентификатор пакета, под которым он в данный момент работает, ссылаясь на API Windows.ApplicationModel.Package.Current. Размещенное приложение – это приложение, которое объявляет зависимость пакета от хоста и использует для активации идентификатор HostRuntime вместо указания исполняемого файла Entrypoint в своем собственном пакете. Обычно он содержит контент, визуальные ресурсы, сценарии или двоичные файлы, к которым хост может получить доступ.

Пакеты размещенных приложений могут быть подписаны или не подписаны:

• Подписанные пакеты могут содержать исполняемые файлы. Это полезно в сценариях, которые имеют механизм расширения, загружать dll или зарегистрированный компонент в пакет размещенного приложения.

• Неподписанные пакеты могут содержать только неисполняемые файлы. Это полезно в сценариях, где hostruntime требуется только для загрузки изображений, ресурсов и контента. Неподписанные пакеты должны включать в свой идентификатор специальный OID неподписанного издателя, иначе им не будет разрешено зарегистрироваться. Это не позволяет неподписанным пакетам подделывать подписанные идентификаторы пакетов.

Объявление о хосте

Объявление хоста довольно просто. Все, что вам нужно сделать, это указать расширение пакета HostRuntime в вашем AppxManifest.xml. Расширение HostRuntime распространяется на весь пакет и поэтому объявляется дочерним элементом пакета. Ниже приведен отрывок из примера AppxManifest.xml, показывающий запись HostRuntime, которая объявляет приложение в качестве хоста с идентификатором «PythonHost».

• hostRuntime – расширение пакета, определяющее информацию о времени выполнения, используемую при активации размещенного приложения.

• Executable – исполняемый двоичный файл, который будет хост-процессом

•RuntimeBehavior и TrustLevel – размещенное приложение будет работать с определениями, выраженными в расширении. Например, размещенное приложение, использующее узел, объявленный выше, будет запускать исполняемый файл PyScriptEngine.exe с уровнем доверия MiddleIL.

• Host Runtime Is – уникальный идентификатор, используемый для указания хоста в пакете. Пакет может иметь несколько приложений хоста, и у каждого должен быть уникальный идентификатор HostRuntime. На этот идентификатор ссылается размещенное приложение.

Объявление о размещении приложения

Размещенное приложение должно объявить зависимость пакета от хоста и указать HostId для использования. Если пакет не подписан, он должен включать OID неподписанного издателя, чтобы удостоверение пакета не конфликтовало с подписанным пакетом. Также TargetDeviceFamily должен соответствовать хосту, поэтому он не пытается развертываться на устройствах, которые не поддерживаются хостом. Ниже приведен пример манифеста для размещенного приложения, который принимает зависимость от хоста Python.

• Unsigned Publisher OID – 2.25.311729368913984317654407730594956997722=1 Этот идентификатор требуется, когда размещенное приложение будет неподписанным. Этот идентификатор гарантирует, что любой неподписанный пакет не сможет подделать удостоверение подписанного пакета.

• HostRuntimeDependency – пакет размещенного приложения должен объявить HostRuntimeDependency в приложении хоста. Он состоит из имени и издателя пакета хоста и минимальной версии, от которой он зависит. Их можно найти в элементе в пакете Host. При развертывании, если HostRuntimeDependency не может быть найден, регистрация завершается неудачно.

• HostId – вместо того, чтобы объявлять обычный исполняемый файл и EntryPoint для приложения или расширения, атрибут HostId выражает зависимость от приложения хоста. В результате размещенное приложение наследует атрибуты Executable, EntryPoint и среды выполнения Host с указанным HostId. При регистрации, если HostId не найден, развертывание не выполняется.

• Parameters  (необязательно) – параметры, которые передаются в командной строке приложению хоста. Хост должен знать, что делать с этими параметрами, и поэтому между хостом и размещенным приложением существует подразумеваемый договор.

Динамическая регистрация для неподписанных размещенных приложений

Одним из преимуществ нового HostRuntime является то, что он позволяет хосту динамически регистрировать пакет размещенного приложения во время выполнения. Этот динамически зарегистрированный пакет не требует подписи. Что позволяет хосту динамически генерировать контент и манифест для пакета размещенного приложения, а затем регистрировать его. Разработчики работают с новым браузером Microsoft Edge, чтобы использовать преимущества модели размещенных приложений для Progressive Web Apps (PWA) – преобразование манифеста веб-приложения в манифест приложения, упаковка дополнительного веб-содержимого в пакет MSIX и его регистрация. В этой модели PWA – это собственное независимое приложение, зарегистрированное в системе, даже если оно размещено на Edge.

Новые API для регистрации пакета:

• Management.Deployment.PackageManager.AddPackageByUriAsync () используется для регистрации пакета MSIX

• Management.Deployment.PackageManager.RegisterPackageByUriAsync () используется для регистрации свободного файла AppxManifest.xml.

В случае, когда размещенное приложение не подписано, его манифест должен соответствовать следующим требованиям:

1. Неподписанный пакет не может содержать никаких атрибутов Executable в своих элементах Application или Extension (например, нет или ), и он не может указывать какие-либо другие данные активации (Executable, TrustLevel и т. д.). Узел приложения поддерживает только элементы HostId и Parameters.

2. Неподписанный пакет должен быть основным типом пакета – он не может быть пакетом Bundle, Framework, Resource или Optional.

В свою очередь, хост-процесс, регистрирующий неподписанный размещенный пакет приложения, должен отвечать следующим требованиям:

1. Процесс должен иметь идентичность пакета

2. Процесс должен иметь возможность управления пакетами

Примеры хоста и размещенного приложения

Давайте посмотрим на два примера. Первый, WinFormsToastHost, – это хост с подписанным размещенным приложением, который показывает, как включить расширение, которое динамически загружается в хост. Второй, NumberGuesser, пример использования python в качестве хоста и файла сценария в качестве пакета размещенного приложения. Вы можете найти пример кода для обоих по адресу https://aka.ms/hostedappsample.

WinFormsToastHost

Хост

Хост в этом примере – это простое приложение Windows Forms, которое отображает идентификацию своего пакета, местоположение и вызывает API-интерфейсы ToastNotification. Он также может загружать двоичное расширение из пакета размещенного приложения. При запуске под собственной идентификацией он не отображает информацию о расширении. Приложение поставляется вместе с проектом упаковки приложений Windows, который включает декларации манифеста о том, что он является хостом.

WinformsToastHost-Extension

Размещенное приложение – это библиотека .NET, которая реализует механизм расширения для загрузки хоста. Он также включает в себя проект упаковки, который объявляет свою идентичность и зависимость от hostruntime. Эта личность будет отображаться в значениях, отображаемых при запуске приложения. После регистрации hostruntime имеет доступ к расположению пакета в hostedapp и, таким образом, может загрузить расширение.

Запуск образца

Вы можете загрузить исходный код в Visual Studio следующим образом:

1. Откройте WinformsToastHost.sln в VS2019

2. Build и deploy  WinformsToastHost.Package

3. Build и deploy HostedAppExtension

4. Перейти в меню «Пуск» и запустить «WinformsToastHost»

5. Перейдите в меню «Пуск» и запустите «Hosted WinformsToastHost Extension»

Вот скриншот работающего хоста. Обратите внимание на его идентификатор пакета и путь, а UX для загрузки сборки недоступен, поскольку он не работает  как размещенное приложение.

Теперь запустите размещенное приложение. Обратите внимание, что идентификатор и путь изменились, и что UX для динамической загрузки сборки расширения включен.

При нажатии кнопки «Run hosted» вы получите диалог из двоичного расширения:

Вот подробное представление диспетчера задач, показывающее, что оба приложения работают одновременно. Обратите внимание, что двоичный файл хоста является исполняемым для обоих:

При нажатии на кнопку «Показать тост» для каждого приложения система распознает две разные личности в центре действий:

NumberGuesser – Игры и  Python

Хост

В этом примере хост состоит из 2 проектов. Первый – это PyScriptEngine, который является оболочкой, написанной на C #, и использует пакет nuget Python для запуска скриптов Python. Эта оболочка анализирует командную строку и имеет возможность динамически регистрировать манифест, а также запускать исполняемый файл python с путем к файлу сценария. Вторым проектом является PyScriptEnginePackage, который представляет собой проект упаковки приложений Windows, который устанавливает PyScriptEngine и регистрирует манифест, который включает расширение HostRuntime.

Хостинг приложения

Размещенное приложение состоит из скрипта Python, NumberGuesser.py и визуальных ресурсов. Он не содержит PE-файлов. Он имеет манифест приложения, в котором объявляются заявления для HostRuntimeDependency и HostId, которые идентифицируют PyScriptEngine в качестве своего хоста. Манифест также содержит запись OID неподписанного издателя, которая требуется для неподписанного пакета.

Запуск образца

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

1. Откройте расширение PyScriptEngine.sln в Visual Studio

2. Установите PyScriptEnginePackage в качестве проекта запуска

3. Сборка PyScriptEnginePackage

4. Развернуть PyScriptEnginePackage

5. Поскольку приложение хоста объявляет appexecutionalias, вы сможете перейти в командную строку и запустить «pyscriptengine», чтобы получить уведомление об использовании:

6. Используйте хост python для регистрации игры Number Guesser из командной строки:

7. Теперь нажмите «Number Guesser (Manifest)» в меню «Пуск» и запустите игру! Посмотрите, сколько попыток нужно, чтобы угадать число:

Давайте подтвердим, что это работает. Обратите внимание, как PyScriptEngine выполняется под идентификатором пакета NumberGuesser!

Подведем итоги!

Таким образом, Microsoft предоставляет нам больше возможностей и возможностей для платформы Windows, и команды рады видеть, какие креативные идеи у вас есть для модели размещенного приложения. В дополнение к Microsoft Edge, ведется разработка с командами по всей компании и ожидается больше приложений, использующих Hosted App Model в будущем.

Источник

Microsoft объявляет о следующем обновлении Windows Community Toolkit версии 6.0, которое стало возможным, благодаря помощи и вкладу нашего сообщества разработчиков. В этом выпуске реализована поддержка ARM64 для инструментария, а также обновление XAML Islands для поддержки .NET Core 3. Кроме того, у нас есть новые функции, такие как элемент управления “Eye Dropper ” и новые помощники уведомлений Win32. У нас также есть обновление Microsoft Graph благодаря XAML контролам.

Смотрите более подробную информацию об этих функциях ниже.

XAML Islands приближает UWP к WPF, WinForms и Win32

XAML  Islands позволяет разработчику улучшить внешний вид и функциональность существующего приложения Win32 для WPF, Windows Forms или C ++, использовать новейшие функции пользовательского интерфейса Windows 10, которые доступны только через UWP контроллы, например, рукописный ввод:

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

Документация для XAML Islands.

Поддержка ARM64

Windows Community Toolkit теперь поддерживает приложения, которые ориентированные на ARM64. Что позволяет разработчикам использовать преимущества времени автономной работы и производительности, работая на собственной архитектуре для таких устройств, как Surface Pro X. Разработчики также тесно сотрудничали с командой Win2D, чтобы убедиться, что она поддерживает ARM64. Это было важно для Lottie и других функций инструментария, основанных на Win2D.

Улучшенная анимация Lottie

Обновление предоставляет больше возможностей Adobe After Effects для Lottie-Windows, в том числе Linear и Radial Gradients, Masks, Track Mattes поддержку codegen для Image Layers . Мы надеемся, что эти дополнения позволят дизайнерам и разработчикам приложений создавать еще более привлекательные визуальные интерфейсы для пользователей Windows 10. Поскольку некоторые из этих функций основаны на более новых SDK, Lottie-Windows теперь также предлагает адаптивное управление версиями. Мы рассчитываем на то, что сообщество определит приоритеты работы с функциями, поэтому, пожалуйста, продолжайте оставлять свои ценные отзывы и предложения для Lottie-Windows!

“Eye Dropper “

Новый элемент управления “Eye Dropper” позволяет вам легко и быстро выбирать цвет приложения.

Документация для EyeDropper.

Превью XAML Graph Controls

Новое дополнение к Windows Community Toolkit позволяет разработчикам легко проходить проверку подлинности и получать доступ к Microsoft Graph в приложениях Windows 10 для создания обширных данных. Эти элементы управления доступны в качестве предварительного просмотра версии 6.1 и будут работать с приложениями UWP и в приложениях WPF / WinForms для Win32 через XAML Islands в .NET Core 3. Кроме того, совсем скоро с помощью Xamarin и Uno Platform у вас появится возможность использовать их на Android и iOS.

Читайте об этих новых элементах управления в нашем официальном заявлении или на GitHub.

Начни сегодня

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

Напоминаем, что вы можете начать работу, следуя нашему учебному пособию docs.microsoft.com tutorial, или просмотреть последние функции, установив образец приложения Windows Community Toolkit из Магазина Microsoft. Если вы хотите внести свой вклад в разработку, пожалуйста, присоединяйтесь на GitHub! Чтобы присоединиться к беседе в Twitter, используйте хештег #WindowsToolkit.

Всем удачного кодирования!

Источник

Предисловие

В сентябре 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, изначально созданной для рабочих нагрузок на сеть и сервер, это помогает понять, могут ли ваши приложения ощутить заметные преимущества от оптимизации времени выполнения. В частности, настольные приложения с сильной зависимостью от операций ввода-вывода файлов, работы в сети и работы с базами данных, скорее всего, увидят улучшения производительности для этих сценариев. Некоторые области, в которых вы можете не заметить значительных изменений, касаются производительности рендеринга пользовательского интерфейса или запуска приложений.

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

<TargetFramework>netstandard2.1TargetFramework>

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

<TargetFramework>netcoreapp3.0TargetFramework>

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

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

или

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

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

Видео

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

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

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

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

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

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

Источник

Как отмечено в этой статье, Windows 10 версии 1909 представляет собой набор функций для повышения производительности, улучшений качества и возможностей компании. Разработчики должны быть в кусе об этой версии, но в настоящее время никаких действий не требуется.

Новый Windows SDK не будет выпущен вместе с этой версией Windows, поскольку в этом релизе не представлены новые API. Это означает, что нет необходимости ориентироваться на Windows 10 версии 1909 или изменять файлы проекта.

Так как обновления SDK пока что нету, вы можете продолжить работу с Windows 10 версии 1903. Это можно сделать самым простым способом, установить Visual Studio 2019.

Новое с Windows 10, версия 1903

Центр разработки Windows имеет полный список того, что доступно для разработчиков, которые используют версию 1903. С тех пор мы презентовали Windows UI Library 2.2.

WinUI 2.2 выпущен в августе. WinUI имеет открытый исходный код, и каждый может ознакомиться с репозиторием WinUI GitHub, чтобы решить проблемы с файлами, обсудить новые функции и даже внести код. В WinUI 2.2 мы добавили новый элемент управления Tab View. Помимо введения новых обновлений Visual Style, был также апдейт для Navigation View. Мы всем рекомендуем использовать WinUI в своих приложениях UWP - это лучший способ получить новейшую систему проектирования Fluent, контроллы и иметь обратную совместимость с Windows 10 Anniversary Update.

2 простых шага для обновления вашей среды разработки

Если вы хотите обновить свою систему Windows 10 до версии 1909, вы можете загрузить ее по подписке VSS, либо воспользоваться WIP (Windows Insider Program) Release Preview Ring. У команды Insider есть отличный пост в блоге, в котором вы узнаете, как попасть в Release Preview Ring. Затем, просто зайдите в Visual Studio 2019 и установите последнюю версию SDK. В последней версии Visual Studio Windows 10 SDK (10.0.18362) уже выбран по умолчанию.

1.      Запустите установщик Visual Studio или перейдите по адресу https://www.visualstudio.com/downloads/ и загрузите его.

2.      Выберите «Universal Windows Platform development» в разделе Workloads, Windows 10 SDK (10.0.18362) будет включен по умолчанию

3.       Нажмите «Install»

Источник

Рост спроса на интегрированные решения для обеспечения безопасности и мониторинга в различных отраслях промышленности привел к быстрому росту рынка видеонаблюдения во всем мире. Сетевые камеры, основанные на интернет-протоколе камеры, которые передают данные по локальной сети (LAN), являются ядром этих решений. Они используются для обеспечения охраны и наблюдения, включая школы, больницы, стадионы, аэропорты и торговые площади. Сетевые камеры также используются в целях безопасности и аналитики, таких как мониторинг загруженности автомагистралей и обстановки на перекрестках.

Мы рады предоставить новые возможности для платформы Windows, которые облегчат создание решений для видеоаналитики на основе безопасности, защиты и машинного обучения в Windows. В Windows10 Insider Build 18995 или более поздней версии мы представляем поддержку для обнаружения, сопряжения, настройки и потоковой передачи для основных поставщиков камер, совместимых с ONVIF Profile S. ONVIF – лидирующая международная организация, лидирующая в этой отрасли. Которая предоставляет стандартизированные интерфейсы для физической защиты на основе IP. Члены ONVIF совместно предлагают более 12 000 профильных продуктов [1].

После подключения к ПК, потоки сетевых камер направляются через существующие API-интерфейсы камеры. Windows обеспечивает высокопроизводительную потоковую передачу видео с сетевых камер в существующие приложения для камер на различных архитектурах, включая x86, AMD64, ARM и ARM64. Благодаря встроенной поддержке сетевых камер разработчики теперь имеют единую платформу для создания решений обеспечения безопасности и мониторинга. Они могут больше сосредоточиться на своей бизнес-логике и меньше беспокоиться о драйверах для камеры или промежуточном программном обеспечении.

Windows обеспечивает поддержку сопряжения камер ONVIF с помощью API WinRT и путем мастера Add a device в Windows 10. Вдобавок, приложения камер, ориентированные на Windows 10 внутри Build 18995 SDK или более поздней версии, могут передавать данные с указанного универсального идентификатора ресурса (URI) RTSP через тот же самый API камеры Windows. Это полезно для решений, в которых используются камеры, не совместимые с ONVIF, или для создания приложений, которые позволяют пользователям просто вводить URI RTSP в качестве источника видео, а не подключать камеру к своему устройству. Подробнее о подключении сетевой камеры к устройству Windows см. В блоге.

Windows также предоставляет разработчикам ИИ-сервисы и возможности для создания высокопроизводительных комплексных решений безопасности. Для общих сценариев наблюдения, таких как распознавание людей или анализ эмоций лиц, Windows Vision Skills предлагает несколько предварительно встроенных модулей компьютерного зрения, которые можно интегрировать в приложения без каких-либо знаний ИИ. Для приложений ИИ с существующими моделями машинного обучения, разработчики могут использовать WinML API-интерфейсы для оценки моделей прямо на устройстве.

[1] https://www.onvif.org/about/mission/

Источник

Windows 10 SDK для May 2019 Update уже доступен с действующей лицензией! Обновление Windows 10 May 2019 Update (сборка 18362) теперь взаимодействует с Release Preview Windows Insider. Она также называется Windows 10, сборка 1903.

Новые API и функции для разработчиков

Каждое Windows 10 обновление выпускается с новыми API, Вы можете ознакомиться с полным списком нововведений для разработчиков на странице Windows Dev Center. Вот некоторые из самых полезных.

1. XAML Islands версия 1: Эта первая версия содержит множество улучшений по сравнению с preview-выпуском в 1809 сборке. Некоторые из основых моментов: устранение проблем незаполненного пространства во всплывающих окнах, XAML содержимое соответствует уровню DPI хоста, Narrator поддерживает работу с XAML содержимым, разрешает islands в нескольких окнах верхнего уровня в одном потоке, поддержка MRT локализации и загрузка ресурсов, ускорители клавиатуры работают в кросс-фреймворках. Windows Community Toolkit версии 6, которая будет выпущенна в июне, будет включать в себя упаковки для WPF и WinForms.

2. Windows Subsystem для Linux: После того, как была выпущена 1903 версия, Вы можете получить доступ к Linux файлам на Windows, а также попробовать более удобные опции командной строки!

1. Теперь Вы можете использовать wslconfig.exe команды в wsl.exe
2. В wsl.exe добавилось несколько новых команд:

• –user,-u : запуск дистрибутив от имени указанного пользователя
• –import : импорт дистрибутив в WSL из архива
• –export : экспорт дистрибутив из WSL в архив
• –terminate, t : завершение работающих дистрибутив

Когда выйдет полный выпуск May 2019 Update:

1. Запустите установщик Visual Studio или перейдите по ссылке https://www.visualstudio.com/downloads/ и загрузите его.
2. Выберите «Разработка на универсальной Windows платформе» в разделе «Рабочие нагрузки», и Windows 10 SDK (10.0.18362) будет включен по умолчанию
3. Нажмите «Установить»

Еще больше полезных советов

Хотите получить инструменты для разработки C ++ или UWP игр? Убедитесь, что Вы уже выбрали один из этих двух:

• Инструменты C ++ разработки для универсальной Windows платформы в разделе «Рабочая UWP нагрузка»
• Десктопная разработка с помощью C ++ Workload и Windows SDK 10 (10.0.18362)
• Если Вы хотите использовать инструменты универсальной Windows платформы, выберите рабочую нагрузку инструментов для Universal Windows Platform

Как только Ваши системы будут обновлены и перекомпилированы, а Ваше приложение протестировано, смело публикуйте его в Dev Center.

Ваше мнение о Windows 10 May 2019 Update

Не забудьте поделиться Вашим опытом, а также личной оценкой функционала нового обновления, написав в Твиттере @ClintRutkas или @WindowsDev.

Известная проблема c негативным влиянием

Существует известная проблема, которая негативно влияет на следующий сценарий при обновлении или установке Windows 10 версии 1903. Когда модуль управления памятью ввода-вывода (IOMMU) работает на VMware Hypervisor, любой гость на виртуальной машине (ВМ) клиента или сервера, который использует IOMMU может перестать работать. Типичные сценарии использования включают в себя, когда для гостевой виртуальной машины включены защита на основе виртуализации (VBS) и защита учетных данных Windows.

На данный момент ведутся активные работы по устранению этой проблемы. Вы должны интегрировать решение в образ клиента перед развертыванием.

Источник

5 марта команда Microsoft Store обновила Соглашение о разработке приложений для Microsoft Store (ADA). В следующий раз, когда Вы войдете в Вашу панель управления (Partner Center), Вам будет предложено повторно принять соглашение о разработке, прежде чем Вы сможете продолжить работу с панелью.

Обновленное соглашение содержит новую структуру платежей в Microsoft Store, которая обеспечивает до 95 процентов дохода для разработчиков потребительских приложений. Чтобы получить полный 95-процентный доход, обязательно указывайте СИД в Ваших ссылках трафика.

Когда Microsoft приносит Вам новых пользователей с помощью других методов (отслеживаемых по СИД), например, когда пользователь устанавливает Ваше приложение с коллекции Microsoft Store, с помощью поиска в Microsoft Store или с помощью любых других опций, принадлежащих Microsoft, Вы получите 85 процентов дохода от этой покупки.

Если покупка не содержит СИД-идентификатор, в случае установки приложения с помощью веб-поиска, Вы получаете 95-процентный доход.

Новая структура оплаты применяется к покупкам приложений на всех ПК под управленим Windows 10, Windows Mixed Reality, Мобильных и Surface Hub устройствах. Новая структура не относится ко всем играм и любым покупкам на Xbox консолях.

Для получения полной информации о новой структуре оплаты см. Соглашение о разработке приложений для Microsoft Store. Чтобы увидеть обзор всех изменений, добавленных в этом обновленисоглашения, пожалуйста, ознакомьтесь с историей изменений. 

Источник

Windows Desktop Bridge - это способ упаковки десктопных приложений для отправки в Microsoft Store или загрузки с любого ресурса. Это один из путей создания MSIX пакета. Вкратце: пользуйтесь им, как современным ClickOnce. Это формат упаковки с поддержкой автоматического обновления и пользователи уверены, что он не нанесет вред их системе и не загрязнит реестр.

Ранее Microsoft объявили о первых предварительных .NET Core 3 и Visual Studio 2019 версиях. Эти пробные варианты поддерживают создание графических ПК приложений с помощью .NET Core с использованием WPF и Windows Forms. Можно перенести существующее приложение из .NET Framework в .NET Core 3. Приложение, которое уже переключилось, – это NuGet Package Explorer; его открытый исходный код уже доступен на GitHub и служит отличным примером.

Если у Вас есть приложение, ориентированное на .NET Core 3, то у Вас могут возникнуть вопросы: «Как мне поделиться этим с моими пользователями?», «.NET Core 3 совершенно новый, у моих пользователей этого не будет!» «Мой IT-отдел не будет выпускать .NET Core 3 в течение года!»

Одна из действительно интересных вещей в .NET Core – это то, что он поддерживает полностью автономные приложения. То есть он не имеет внешних зависимостей. Вам не нужно ничего устанавливать, даже сам .NET Core. Вы можете скопировать вывод публикации проекта и передать его кому-нибудь для запуска. Это открывает огромные возможности, так как Вы, как разработчик, можете использовать нужные Вам фреймворки и рабочие версии, не беспокоясь о том, что помешаете другим приложениям, запущенным на компьютере, даже если рабочий вариант уже существует в box.

С полностью автономным приложением Вы сможете использовать Desktop Bridge для упаковки Вашей программы, чтобы пользователи легко могли её установить. На сегодняшний день шаблоны не поддерживают этот нестандартный сценарий, но, настроив должным образом, его можно запустить.

Вначале

Вам понадобится Visual Studio 2017 15.9 или, еще лучше, новый выпуск Visual Studio 2019 Preview. В настройках обязательно выберите рабочую нагрузку UWP для установки инструментов проекта упаковки. Загрузите .NET Core 3 Preview и создайте в нем первое WPF .NET Core приложение.

Подробно

В официальных документах описано, как добавлять проект упаковки в Ваше приложение. Microsoft советует начать с этого. В будущем, как только инструмент начнет работать, Вам будет достаточно этой информации. На данный момент, в качестве временного решения, в статье будут изложены основные принципы.

Здесь Вы можете ознакомиться с готовым продуктом. Различия, показывающие определенные изменения, здесь.

Цель состоит в том, чтобы проект упаковки сам выполнял публикацию в основном приложении, а затем использовал эти выходные данные в качестве входных данных для упаковки. Изменения необходимо внести в следующие файлы:

1. Основной проект приложения, пример NetCoreDesktopBridgeApp.csproj.
2. Проект упаковки, пример NetCoreDesktopBridgeApp.Package.wapproj.

Проект приложения

Начнем с основного проекта приложения, .csproj или .vbproj файла. Добавьте win-x86 к первой . Это гарантирует, что восстановление NuGet предоставит ресурсы, специфичные для среды выполнения, и поместит их в project.assets.json файл. Затем вставьте следующее:

  
    <_PublishItem Include="@(ResolvedFileToPublish->'%(FullPath)')" TargetPath="%(ResolvedFileToPublish.RelativePath)" OutputGroup="__GetPublishItems">
    <_PublishItem Include="$(ProjectDepsFilePath)" TargetPath="$(ProjectDepsFileName)">
    <_PublishItem Include="$(ProjectRuntimeConfigFilePath)" TargetPath="$(ProjectRuntimeConfigFileName)">
  

Полный файл проекта должен выглядеть следующим образом:

  


  
    WinExe
    netcoreapp3.0
    true

    
    win-x86
  

  
  
    
      <_PublishItem Include="@(ResolvedFileToPublish->'%(FullPath)')" TargetPath="%(ResolvedFileToPublish.RelativePath)" OutputGroup="__GetPublishItems">
    <_PublishItem Include="$(ProjectDepsFilePath)" TargetPath="$(ProjectDepsFileName)">
    <_PublishItem Include="$(ProjectRuntimeConfigFilePath)" TargetPath="$(ProjectRuntimeConfigFileName)">
    
  

Проект упаковки

Далее нужно добавить в (.wapproj) проект упаковки следующее, еще одно свойство:

 CoreClr

в , которая включает DefaultLanguage и EntryPointProjectUniqueName. Так Visual Studio говорит применять .NET Core отладчик. Примечание: чтобы использовать этот параметр, после установки Вам, возможно, нужно будет разгрузить / перезагрузить проект для VS. Если после изменения этого свойства система выдаст странную ошибку отладки, перезапустите VS, загрузите решение, и все должно заработать.

Затем найдите элемент. Если его нет, щелкните правой кнопкой мыши на Application node и добавьте ссылку на приложение в Ваш основной проект. Добавьте следующие атрибуты: SkipGetTargetFrameworkProperties = "true" Properties = "RuntimeIdentifier = win-x86; SelfContained = true". Полная ItemGroup должна выглядеть примерно так:

  @(PackageOutputGroups);__GetPublishItems
 
В этом фрагменте измените NetCoreDesktopBridgeApp\NetCoreDesktopBridgeApp.exe, чтобы он соответствовал имени и исполняемому файлу Вашего основного проекта.
Обходное решение VCRedist
В качестве контрольной точки Вам нужно указать зависимость пакета от VCRedist в Package.appxmanifest файле. Добавьте в  элемент следующее: 

. Когда пользователи установят Ваше приложение, Windows автоматически подтянет эту зависимость из хранилища.
 
Сборка и отладка
С указанными выше компонентами, Вы можете установить проект упаковки в качестве стартапа и выполнить отладку в обычном режиме. Он создаст программу и развернет его в локальном приложении. Выходные данные можно увидеть в bin\AnyCPU\\AppX каталоге Вашего проекта упаковки. Он должен содержать больше файлов, чем в вашем главном приложении, поскольку в нем будет автономная .NET Core среда выполнения.
Примечание. Иногда отладка проекта упаковки не приводит к восстановлению, если в нем были изменены некоторые файлы. Восстановление основного проекта приложения исправляет это, и Вы можете настраивать то, что ожидаете получить.
Развертывание приложения
Существует два основных варианта развертывания пакета:
 

Загрузка с помощью AppInstaller файла. Это замена ClickOnce.
Microsoft Store. Пакет может быть отправлен в Store для распространения.

 
Двойная загрузка
Начиная с Windows 10 1803, загруженные приложения могут автоматически обновляться с помощью .appinstaller файла. AppInstaller является альтернативой ClickOnce для большинства сценариев. В документации описывается, как создать этот файл при публикации и поместить его в UNC-путь, общую папку или HTTPS-папку.
Если Вы загружаете контент, то нужно использовать сертификат подписи кода, которому доверяют Ваши пользователи. Для предприятия это может быть документ внутреннего центра сертификации, для общественности он должно быть получен в государственном органе. У DigiCert есть отличное предложение для сертификатов подписи кода, $ 74 / год для обычного и $ 104 / год для EV по специальной ссылке. После получения сертификата Вам необходимо обновить Package.appxmanifest, чтобы использовать его. В данной статье нет информации об автоматической подписи кода, но Вы можете ознакомиться с проектом службы подписи кода здесь.
Microsoft Store
Microsoft Store – отличный способ, чтобы Ваши пользователи узнали о приложении. Он обрабатывает подписывание кода, распространение и обновление. Более подробная информация о том, как подать приложение в Store, здесь и здесь.
 
Источник