Winrt что это

Небольшое сравнение производительности UWP/WinRT API языковых проекций

На мой взгляд, в разработке UWP/WinRT приложений сложилась необычная ситуация: компания продвигает использование нативного SDK из управляемой среды. Мне стало интересно, насколько эффективен данный подход. И для ответа, я решил написать несколько приложений, решающих одну и туже задачу, полагаясь на средства предоставляемые UWP/WinRT API.
За результатами моего небольшого теста добра пожаловать под кат.

Постановка задачи

1. Исполняемой средой вызывается функция Main()(не удивляйтесь, в приложения WinRT/UWP эта функция всегда существует)
2. Методу CoreApplication.Run(…) передаётся реализация IFrameworkViewSource, которая возвращает в методе CreateView() интерфейс IFrameworkView
3. Через несколько шагов инициализации вызывается метод IFrameworkView.Run(), который выполняет активацию основного окна приложения, запускает обработку событий диспетчером и создаёт поток/задачу для выполнения вычислений

1. Инициализация переменных
2. Запуск таймера/инициализация переменной времени начала
3. Многократное преобразование: входные данные -> SHA256 хэш -> Base64 строка -> входные данные
4. Остановка таймера/вычисление пройденного времени
5. Запись значений в локальные настройки

• CPP (C++). Сишные реализации алгоритмов были взяты из github.com/B-Con/crypto-algorithms.
• CPPCX (C++ CX). Использует API CryptographicBuffer, предоставляемого UWP/WinRT.
• CPPWRL(C++). Также использует API CryptographicBuffer, но вызовы осуществляются в манере COM.
• CS(C#). Взята реализации из github.com/yuriks/SHA2-Csharp/blob/master/Sha256.cs.
• CSWinRT(C#). Используется API CryptographicBuffer.

Результаты тестирования

Тестирование проводилось в двух режимах компиляции и исполнения: ARM и x86.
Ниже представлены диаграммы времени исполнения(значения указаны в миллисекундах).

Столь значительная разница меня немного удивила. Чтобы разобраться я решил провести профилирование приложений, использующих UWP/WinRT API.
Если свести все скриншоты в таблицу то, можно получить следующее:

Легко заметить причину столь большой разницы: в проекте, написанном на чистом C++ с использованием WRL, время работы кода из библиотеки CryptoWinRT.dll, достигает значения 90 процентов, а в проекте C#, скомпилированном с использованием .NET Native, это значение равно всего 15 процентам. Вот и получается, что большую часть времени проекты, написанные на C#, работают в холостую.

Заключение

Конечно, понятно то, что выбран отдалённый от реальности метод использования UWP/WinRT API. Скорее всего в жизни такой код вообще никогда не встретится. Но факт остаётся фактом, при некотором стечении обстоятельств, ваш код может работать очень медленно только из-за накладных расходов, возникших в следствии использования языковой проекции. Может быть наилучшим решением в этом случае будет альтернативная реализация, выполняющая аналогичные задачи, но без использования системного API.

Исходный всех проектов код доступен по ссылке https://github.com/altk/sha256comparison

• .NET
• C++
• Разработка под Windows Phone
• C#
• Разработка под Windows

Windows Runtime

Windows Runtime, или WinRT — это новая(по состоянию на 2011 год) модель программирования от Microsoft, являющаяся основой для разработки приложений в стиле Метро в новой операционной системе Windows 8 [1] [2] . WinRT поддерживает разработку на C++ (обычно с использованием расширения языка Component Extensions, C++/CX), управляемых языках C# и VB.NET, а также JavaScript.

WinRT по существу является API на основе технологии COM. Из-за своей COM-подобной основы, WinRT позволяет относительно легко обращаться к нему из различных языков программирования, как это происходит в COM, но это, по существу, неуправляемый, родной API. Определения API хранятся в «.winmd» файлах, закодированных в формате метаданных ECMA 335, который используется в .Net с некоторыми изменениями. [3] Этот общий формат метаданных позволяет значительно уменьшить накладные расходы при вызове WinRT из .NET приложений по сравнению с P/Invoke, имея при этом намного более простой синтаксис. [4] Новый язык C++/CX (Component Extensions), который заимствует некоторые элементы синтаксиса из C++/CLI, позволяет создавать и использовать WinRT-компоненты с меньшим количеством видимой для программиста обвязки по сравнению с классическим программированием COM в C++, и в то же время накладывает меньше ограничений по сравнению с C++/CLI на смешение типов. Обычный С++ (с COM-специфичными требованиями) также может быть использован для программирования с компонентами WinRT. [5] Это возможно с помощью новой библиотеки шаблонов Windows Runtime C++ Template Library (WRL), которая аналогична по своей цели тому, что библиотека ATL обеспечивает для COM. [6] Документация MSDN однако рекомендует использовать C++/CX вместо WRL. [7]

Примечания

1. ↑Abel AvramDesign Details of the Windows Runtime. InfoQ (21 September 2011). Архивировано из первоисточника 11 сентября 2012.
2. ↑Brian Klug & Ryan SmithMicrosoft BUILD: Windows 8, A Pre-Beta Preview. AnandTech (13 September 2011). Архивировано из первоисточника 11 сентября 2012.
3. ↑WinRT demystified — Miguel de Icaza
4. ↑http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/d510d916-a090-412c-a17f-e4421ad9a137/
5. ↑Visual C++ and WinRT/Metro — Some fundamentals — CodeProject®
6. ↑Using the Windows Runtime from C++ | BUILD2011 | Channel 9
7. ↑Windows Runtime C++ Template Library

Ссылки

• Документация по WinRT (предварительный просмотр) на Windows Dev Center

• Microsoft Windows

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое «Windows Runtime» в других словарях:

• Windows Runtime — Entwickler Microsoft Corporation Aktuelle Vorabversion 6.2.8102.0 (30. August 2011) Betriebssystem Microsoft Windows 8 Developer Preview Kategorie Laufzeitumgebung Lizenz … Deutsch Wikipedia
• Windows 2.0 — Part of the Microsoft Windows family … Wikipedia
• Windows 2.0 — Windows 2.x Bildschirmfoto … Deutsch Wikipedia
• Windows 2.x — Bildschirmfoto … Deutsch Wikipedia
• Windows Store — Entwickler Microsoft Corporation Betriebssystem Windows 8 (Developer Preview) Der Windows Store (von Windows nach dem gleichnamigen Betriebssystem und engl. Store = Geschäft) ist ein zukünftiges Internet Verkaufsportal vom Softwarehersteller… … Deutsch Wikipedia
• Windows RT — Разработчик Microsoft Семейство ОС Windows Исходный код Закрытый исходный код Первый выпуск 26 октября 2012 года[1] Поддерживаемые языки … Википедия
• Windows PowerShell — Screenshot of a sample PowerShell session … Wikipedia
• Windows Vista — Part of the Microsoft Windows family … Wikipedia
• Windows PowerShell — Windows PowerShell … Википедия
• Windows Media Player — A component of Microsoft Windows Details … Wikipedia

• Обратная связь: Техподдержка, Реклама на сайте

• �� Путешествия

Экспорт словарей на сайты, сделанные на PHP,
WordPress, MODx.

• Пометить текст и поделитьсяИскать в этом же словареИскать синонимы
• Искать во всех словарях
• Искать в переводах
• Искать в ИнтернетеИскать в этой же категории

Простое приложение WinRT

Пользовательский интерфейс Windows 8 реализует новую парадигму проектирования, которая с большой вероятностью будет отражена в приложениях Windows Store. Эта парадигма, отчасти вдохновленная городскими вывесками, ставит на первое место содержание, а не программный «хром»; для нее характерно использование простых шрифтов, четкого и открытого стиля оформления, интерфейса на базе плиток и переходных анимаций.

Многие разработчики познакомились с парадигмой проектирования Windows 8 в системе Windows Phone 7; интересно проследить за тем, как изменялось отношение Microsoft к большим и малым компьютерам. За прошедшие годы компания пыталась приспособить архитектуру традиционных настольных приложений Windows к малым устройствам — мобильным компьютерам и телефонам. Теперь дизайн пользовательского интерфейса телефона проникает на планшеты и настольные системы.

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

Windows Phone 8 является конкурентом для популярных мобильных операционных систем, таких как Android и iOS. Для разработки бесплатных программ на айпад и айфон используются совершенно другие языки программирования и платформы (Java для Android и Objective-C для iOS). В настоящее время для приложений Windows 8 существуют три основных варианта программирования, каждый из которых основан на определенном языке программирования и языке разметки:

• C++ и XAML;
• C# или Visual Basic и XAML;
• JavaScript и HTML5.

В этой и последующих статьях мы будем использовать второй вариант. Давайте создадим простой пример, чтобы продемонстрировать возможности WinRT. Предполагается, что на вашем компьютере установлена система Windows 8 или Windows 8.1, а также новейшая версия Microsoft Visual Studio, поддерживающая создание приложений Windows 8. Запустите Visual Studio со стартового экрана Windows 8. Пора браться за программирование!

Первый проект

На исходном экране Visual Studio выберите команду New Project в меню File. Когда на экране появится диалоговое окно New Project, выберите слева категорию Templates, затем подкатегорию Visual C# и строку проекта Windows Store. В списке доступных шаблонов в центральной области выберите тип пустого приложения (Blank App). В нижней части диалогового окна введите в поле Name имя проекта — например, WinRTTestApp. Оставьте в поле Solution Name то же имя решения. При помощи кнопки Browse выберите каталог для программы и щелкните на кнопке ОК. (Говоря об операциях с Visual Studio, я будут использовать «мышиную» терминологию — «щелкнуть» и т.д, но когда речь пойдет о приложениях, которые вы будете создавать, я перейду на терминологию сенсорных экранов — «коснуться» и т.д. Вероятно, версия Visual Studio, оптимизированная для сенсорного ввода, появится в ближайшие годы.)

Visual Studio создаст решение с именем WinRTTestApp, проект WinRTTestApp в этом решении, а также набор файлов в проекте. Эти файлы перечислены в окне Solution Explorer в правой части экрана Visual Studio. Каждое решение Visual Studio содержит хотя бы один проект, но решение может содержать дополнительные проекты приложений и библиотек.

В список файлов этого проекта входит файл с именем MainPage.xaml. Щелкнув маленькой стрелке рядом с этим файлов вы увидите файл с именем MainPage.xaml.cs смещенный вправо от MainPage.xaml:

Любой из этих двух файлов можно просмотреть — сделайте двойной щелчок на имени файла или же щелкните правой кнопкой мыши на имени и выберите команду Open.

Файлы MainPage.xaml и MainPage.xaml.cs включены в окно Solution Explorer, потому что каждый из них вносит свой вклад в определение класса MainPage. В простых программах, таких как наша, класс MainPage определяет все визуальные аспекты и пользовательский интерфейс приложения.

Несмотря на странное имя, файл MainPage.xaml.cs определенно имеет расширение .cs, то есть содержит код C#. Если убрать из файла все комментарии, базовый код C# в MainPage.xaml.cs выглядит так:

using System; using System.Collections.Generic; using System.IO; using System.Linq; using System.Runtime.InteropServices.WindowsRuntime; using Windows.Foundation; using Windows.Foundation.Collections; using Windows.UI.Xaml; using Windows.UI.Xaml.Controls; using Windows.UI.Xaml.Controls.Primitives; using Windows.UI.Xaml.Data; using Windows.UI.Xaml.Input; using Windows.UI.Xaml.Media; using Windows.UI.Xaml.Navigation; namespace WinRTTestApp < public sealed partial class MainPage : Page < public MainPage() < this.InitializeComponent(); >> > 

Большое место в этом файле занимают директивы using для всех пространств имен, которые, как предполагается, понадобятся для работы программы. Впрочем, в большинстве файлов MainPage.xaml.cs нужны не все перечисленные пространства имен, а во многих файлах требуются дополнительные пространства.

Пространства имен делятся на две общие категории по префиксу имени:

• System.*** — пространства имен из базовых сборок платформы .NET Framework для новых приложений Windows 8;
• Windows.*** — пространства имен из сборки Windows Runtime (или WinRT).

Как можно предположить по виду списка директив using, пространства имен, начинающиеся с Windows.UI.Xaml, играют важную роль в работе Windows Runtime.

После директив using в файле MainPage.xaml.cs определяется пространство имен с именем WinRTTestApp (тем же, что и в имени проекта) и класс MainPage, производный от Page — класса, который является частью Windows Runtime.

Документация Windows 8 API упорядочена по пространствам имен. Если вы хотите найти документацию класса Page, информация о пространстве имен, в котором этот класс определен, упростит поиск. Наведите указатель мыши на имя Page в исходном коде MainPage.xaml.cs; вы увидите, что класс Page находится в пространстве имен Windows.UI.Xaml.Controls (вы можете нажать клавишу F1 в Visual Studio для загрузки описания класса на MSDN).

Конструктор класса MainPage вызывает метод InitializeComponent() (о котором мы вскоре поговорим подробнее).

Обратите внимание на ключевое слово partial в определении класса MainPage. Это ключевое слово обычно означает, что определение класса продолжается в другом файле с исходным кодом C#. Как вы вскоре убедитесь, в нашем случае дело обстоит именно так, однако недостающей частью класса MainPage является не другой файл с кодом C#, а файл MainPage.xaml:

Файл состоит из разметки в стандарте, известном как — произносится «зэмл». И как подсказывает название, XAML происходит от языка XML.

Обычно файл в формате XAML используется для определения визуальных элементов страницы, а файл C# делает то, что нельзя сделать в разметке — например, обрабатывает данные и реагирует на ввод данных пользователем. Файл C# часто называют файлом отделенного кода (code-behind file) для соответствующего файла XAML. Подобная модель компоновки приложений принята во многих архитектурных платформах .NET (WPF, Silverlight, ASP.NET Web Forms) и должна быть вам знакома, если вы с ними работали.

Корневой элемент файла XML — Page — уже известен вам как класс Windows Runtime. Но обратите внимание на атрибут:

x:Class="WinRTTestApp.MainPage"

Атрибут x:Class может присутствовать только в корневом элементе файла XAML. Этот конкретный атрибут означает «класс с именем MainPage в пространстве имен WinRTTestApp определяется как производный от Page». Он означает то же, что и определение класса в файле C#!

Далее следуют объявления пространств имен XML. Как обычно, эти URI не подразумевают фактического обращения к веб-страницам, а служат уникальными идентификаторами, поддерживаемыми некоторыми компаниями или организациями. Первые два пространства особенно важны:

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

В 2006 году компания Microsoft представила Windows Presentation Foundation; тогда же состоялся дебют XAML. Технология WPF была частью платформы .NET Framework 3.0, которая до выпуска обозначалась сокращением WinFX, отсюда и «winfx» в URI. Файлы XAML в определенной степени совместимы с WPF, Silverlight, Windows Phone и Windows Runtime, но только в том случае, если они используют классы, свойства и функции, общие для всех сред.

Первое объявление пространства имен без префикса относится к открытым классам, структурам и перечислениям, определенным в Windows Runtime; в эту категорию входят все элементы управления и вообще все, что может включаться в файл XAML, включая классы Page и Grid конкретного файла. Слово представление (presentation) в URI относится к визуальному пользовательскому интерфейсу, и это отличает его от других типов приложений, использующих XAML. Например, при использовании XAML для Windows Workflow Foundation (WF) в конце URI пространства имен по умолчанию стояло бы слово «workflow».

Второе объявление пространства имен связывает префикс «x» с элементами и атрибутами, принадлежащими XAML. Только девять из них могут использоваться в приложениях Windows Runtime; и конечно, самым важным является атрибут x:Class.

Третье объявление пространства имен выглядит интереснее:

xmlns:local="using:WinRTTestApp"

Оно связывает префикс XML local с пространством имен WinRTTestApp данного конкретного приложения. Если вы создадите в своем приложении пользовательские классы, для обращения к ним в XAML будет использоваться префикс local. Если вам потребуется обращаться к классам из библиотек программного кода, вы определите дополнительные объявления пространств имен XML с указанием имен сборок и пространств имен этих библиотек. Позднее вы увидите, как это делается.

Оставшиеся объявления пространств имен предназначены для Microsoft Expression Blend. Expression Blend может вставлять собственную разметку, которая должна игнорироваться компилятором Visual Studio; отсюда атрибут ignorable, требующий еще одного объявления пространства имен. В любой программе из последующих примеров три последних строки корневого элемента Page можно удалить.

У элемента Page имеется дочерний элемент с именем Grid — еще один класс, определенный в пространстве имен Windows.Ul.Xaml.Controls. Иногда его называют «контейнером», так как Grid может содержать другие визуальные объекты, но формально правильнее называть его «панелью», так как он является производным от класса Panel. Классы, производные от Panel, играют очень важную роль в структуре макета приложений Windows 8 и определяют их компоновку. В файле MainPage.xaml, который Visual Studio создает за вас, элементу Grid назначается цвет фона (на самом деле объект Brush) с использованием заранее определенного идентификатора и синтаксиса, используя ресурсы.

В общем случае Grid делится на строки и столбцы для определения отдельных ячеек — что-то вроде значительно усовершенствованной таблицы HTML или просто сетки. Впрочем, элемент Grid без строк и столбцов тоже способен принести немалую пользу.

Для вывода абзаца текста в Windows Runtime обычно используется элемент управления TextBlock (еще один класс, определенный в пространстве имен Windows.UI.Xaml.Controls). Давайте разместим элемент TextBlock в Grid с одной ячейкой и назначим ему набор атрибутов. В действительности эти атрибуты являются свойствами, определяемыми классом TextBlock:

Порядок следования атрибутов роли не играет, как, разумеется, и отступы. Если вы очень торопитесь, все атрибуты, кроме Text, можно опустить. В процессе ввода текста функция Visual Studio IntelliSense предлагает имена атрибутов и возможные значения. Часто достаточно выбрать нужный вариант из списка. А когда вы завершаете ввод TextBlock, в представлении конструирования (конструктор представления, design view) Visual Studio отображается внешний вид страницы.

Также можно обойтись вообще без ввода, просто перетащить TextBlock из палитры инструментов Toolbox в Visual Studio, а затем задать свойства в таблице, но я так поступать не стану. Процесс создания программ будет описываться так, словно мы с вами вводим код и разметку с клавиатуры, как настоящие программисты.

Программу можно запустить в эмуляторе с возможностью управления разрешением, ориентацией и другими характеристиками. На панели инструментов Visual Studio находится раскрывающийся список, в котором выбрана строка Local Machine; замените ее строкой Simulator. Нажмите F5 , чтобы откомпилировать и запустить программу, или выберите команду Start Debugging в меню Debug. Даже такие простые программы желательно запускать в отладчике Visual Studio:

Атрибуты HorizontalAlignment и VerticalAlignment элемента TextBlock обеспечили выравнивание текста по центру, а вам как программисту не пришлось явно определять размер отображаемой области и размер выводимого текста. Также атрибуту HorizontalAlignment можно задать значение Left или Right, а атрибуту VerticalAlignment — значение Тор или Bottom, чтобы разместить TextBlock в одном из девяти мест Grid. Windows Runtime поддерживает возможность точного размещения визуальных объектов в пикселах, но обычно лучше использовать встроенные средства формирования макета.

У элемента TextBlock есть свойства Width и Height, но обычно задавать их не обязательно. Более того, задание свойств Width и Height в этом конкретном случае может привести к отсечению части текста или нарушению выравнивания текста по центру страницы. Элемент TextBlock умеет определять свои размеры лучше вас.

Программа может быть запущена на устройстве, реагирующем на изменение ориентации — например, на планшете. В этом случае вы заметите, что содержимое страницы динамически изменяется при изменении ориентации и пропорций, не требуя каких-либо действий со стороны программы. Всю основную работу выполняют Grid, TextBlock и система формирования макета Windows 8.

Чтобы завершить выполнение программы, нажмите клавиши Shift+F5 в Visual Studio или выберите команду Stop Debugging в меню Debug. Вы увидите, что программа не только была выполнена, но и стала доступной на начальном экране. Если вы сами создали проект, плитка выглядит не слишком впечатляюще, однако плитки программы хранятся в каталоге Assets проекта, так что при желании вы можете украсить их. Программу можно повторно запустить вне отладчика Visual Studio прямо с начального экрана Windows 8.

Графическое приветствие

Традиционные программы «Hello world» выводят приветствие в текстовом виде, но это не единственный вариант. Давайте используем растровое изображение с моего веб-сайта при помощи крошечного фрагмента разметки XAML:

Элемент Image определен в пространстве имен Windows.UI.Xaml.Controls; это стандартный механизм вывода растровых изображений в программах Windows Runtime. По умолчанию изображение масштабируется так, чтобы заполнить все выделенное место с сохранением исходных пропорций. При уменьшении страницы (например, из-за изменения ориентации устройства или активизации режима Snap View) размеры изображения изменяются в соответствии с новыми размерами страницы. Стандартный режим вывода изображения можно изменить при помощи свойства Stretch элемента Image. По умолчанию используется значение перечисляемого типа Stretch.Uniform. Попробуйте заменить его на Fill — изображение будет заполнять контейнер без сохранения пропорций:

Если свойство Stretch равно None, изображение выводится с исходными размерами (800 х 450). Местонахождением изображения на странице можно управлять при помощи тех же свойств HorizontalAlignment и VerticalAlignment, которые используются с TextBlock. При четвертом значении свойства Stretch — UniformToFill — контейнер заполняется с сохранением пропорций изображения. Это может быть сделано только одним способом: обрезкой изображения. Выбор отсекаемой части зависит от свойств HorizontalAlignment и VerticalAlignment.

Загрузка растрового изображения по сети зависит от наличия сетевого подключения, и даже при его наличии может потребовать некоторого времени. Чтобы гарантировать доступность изображения, лучше включить его в само приложение. Windows Runtime поддерживает популярные графические форматы BMP, JPEG, PNG и GIF, а также некоторые менее распространенные форматы. Для таких изображений, как наше, чаще всего используется формат PNG; сохраните его под именем win8logo.png.

Обычно для хранения растровых изображений, используемых проектом, используется каталог с именем Images. В окне Solution Explorer щелкните правой кнопкой мыши на имени проекта, выберите команды Add и New Folder. (Или если проект выделен в Solution Explorer, выберите команду New Folder в меню Project.) Введите имя папки, например, Images.

Теперь щелкните правой кнопкой мыши на папке Images, выберите команды Add и Existing Item. Перейдите к сохраненному ранее файлу win8logo.png и щелкните на кнопке Add. Когда файл будет добавлен в проект, щелкните правой кнопкой мыши на имени файла и выберите команду Properties. Убедитесь в том, что на панели свойств в поле Build Action выбран пункт Content — изображение должно стать частью содержимого приложения.

Файл XAML со ссылкой на изображение очень похож на аналогичный файл для обращения к изображению в Интернете:

Обратите внимание: в свойстве Source указывается папка и имя файла. Некоторые программисты предпочитают хранить графику, используемую в приложении, в папке с именем Assets. В стандартный проект включается папка Assets с изображениями логотипа приложения; вы можете использовать ее для своих изображений, вместо того чтобы создавать отдельную папку.

C#/WinRT

C#/WinRT — это набор средств в виде пакета NuGet, обеспечивающий поддержку проекций среды выполнения Windows (WinRT) для языка C#. Сборка проекции представляет собой сборку взаимодействия, которая позволяет программировать API-интерфейсы WinRT естественным и привычным способом для целевого языка. Проекция C#/WinRT скрывает сведения о взаимодействии между интерфейсами C# и WinRT и обеспечивает сопоставление многих типов WinRT соответствующим эквивалентам .NET, например строкам, URI, общим типам значений и универсальным коллекциям.

В настоящее время C#/WinRT обеспечивает поддержку использования интерфейсов API WinRT с помощью моникеров целевой платформы (TFM) в .NET. При указании моникера целевой платформы с определенной версией Windows SDK добавляются ссылки на проекцию Windows SDK и сборки среды выполнения, созданные C#/WinRT.

Пакет NuGet для C#/WinRT позволяет создавать собственные сборки взаимодействия WinRT для потребителей .NET и ссылаться на них. Кроме того, последняя версия C#/WinRT включает предварительную версию для создания типов WinRT в C#.

Обоснование для использования C#/WinRT

.NET (прежнее название — .NET Core) — это кроссплатформенная среда выполнения с открытым кодом, с помощью которой можно создавать приложения для устройств, облаков и Интернета вещей.

В предыдущие версии .NET Framework и .NET Core были встроены средства поддержки технологии Windows под названием WinRT. Для обеспечения переносимости и эффективности .NET 6 и более поздних версий мы отключили поддержку проекций WinRT в компиляторе и среде выполнения .NET и включили ее в наборе инструментов C#/WinRT (см. статью Встроенная поддержка WinRT отключена в .NET). Задача C#/WinRT заключается в обеспечении такого же уровня поддержки WinRT, как и в более ранних версиях компилятора C# и среды выполнения .NET. Дополнительные сведения см. в статье Сопоставление типов .NET с типами среды выполнения Windows.

C#/WinRT также поддерживает компоненты в пакете SDK для приложений для Windows, включая WinUI 3. Пакет SDK для приложений для Windows выводит из ОС собственные элементы управления пользовательским интерфейсом Майкрософт и другие собственные компоненты. Это позволяет разработчикам приложений использовать новейшие элементы управления и компоненты в Windows 10 версии 1809 и выше.

Наконец, C#/WinRT является общим набором средств и предназначен для поддержки других сценариев, при которых встроенная поддержка WinRT недоступна в компиляторе C# или в среде выполнения .NET.

Новые возможности

Последние выпуски C#/WinRT можно найти на странице заметок о выпуске в репозитории GitHub.

Использование

Пакет NuGet для C#/WinRT можно использовать для создания проекций C# (также называемых сборками взаимодействия) из компонентов WinRT и при работе со статье Создание компонентов C#/WinRT. Дополнительные сведения о сценариях использования C#/WinRT см. в нашем репозитории в этом руководстве .

Создание и распространение сборки взаимодействия

API-интерфейсы WinRT определены в файлах метаданных Windows (WinMD). Пакет NuGet для C#/WinRT (Microsoft.Windows.CsWinRT) включает компилятор C#/WinRT (cswinrt.exe), с помощью которого можно обрабатывать файлы WinMD и создавать код C# для .NET. C#/WinRT на основе этих файлов компилирует сборку взаимодействия, аналогично тому, как C++/WinRT создает заголовки для проекции языка C++. Затем вы можете распространить сборку взаимодействия C#/WinRT вместе со сборкой реализации для создания ссылок на приложения .NET, обычно в виде пакета NuGet.

Дополнительные сведения о создании и распространении сборки взаимодействия см. в статье Создание проекции C# из компонента C++/WinRT и ее распространение в формате NuGet для приложений .NET.

Ссылка на сборку взаимодействия

Как правило, на сборки взаимодействия C#/WinRT ссылаются проекты приложений. Однако на них также могут ссылаться промежуточные сборки взаимодействия. Например, сборка взаимодействия WinUI ссылается на сборку взаимодействия Windows SDK.

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

Поддержка внедрения для типов WinRT (предварительная версия)

Начиная с версии C#/WinRT 1.4.1, включена поддержка внедрения проекции Windows SDK и источников среды выполнения для .NET и .NET Standard 2.0 в библиотеку или выходные данные приложения. Это полезно в случаях, когда использование типов Windows SDK является автономным. Поддержка внедрения устраняет зависимости от WinRT.Runtime.dll и Microsoft.Windows.SDK.NET.dll, что сокращает размер библиотеки или выходных данных приложения. Это также позволяет разработчикам библиотек предоставлять поддержку предыдущих версий и исключать настройку для разных версий.

Дополнительные сведения см. в документации по встраиванию C#/WinRT в нашем репозитории.

Активация типа WinRT

C#/WinRT поддерживает активацию типов WinRT, размещенных в операционной системе, а также сторонних компонентов, например Win2D. Поддержка активации сторонних компонентов в классическом приложении включена с активацией бесплатной регистрации WinRT (см. статью «Повышение непакетированных классических приложений с помощью компонентов среда выполнения Windows»), доступной в Windows 10 версии 1903 и более поздних версий. Собственные компоненты C++ должны установить для свойства Windows Desktop Compatible значение True либо через свойства проекта, либо через файл .vcxproj , чтобы ссылаться на двоичные файлы Microsoft.VCLibs.Desktop и пересылать их потребляющим приложениям. В противном случае для использования приложений потребуется пакет VCRT Forwarders, если компонент предназначен только для приложений UWP.

C#/WinRT также предоставляет резервный путь активации, если Windows не удается активировать тип, как описано выше. В этом случае C#/WinRT пытается определить расположение собственной библиотеки DLL реализации на основе полного имени типа, постепенно удаляя элементы. Например, резервная логика попытается активировать тип Contoso.Controls.Widget из перечисленных ниже модулей в такой последовательности:

1. Contoso.Controls.Widget.dll
2. Contoso.Controls.dll
3. Contoso.dll

C#/WinRT использует для поиска библиотеки DLL реализации альтернативный порядок поиска LoadLibrary. Пакет приложения, в котором предусмотрено использование такого резервного способа, наряду с модулем приложения должен включать библиотеку DLL реализации.

Распространенные ошибки и устранение неполадок

• Ошибка: «Метаданные Windows не предоставляются или не обнаружены». Метаданные Windows можно указать с помощью свойства проекта , например:

10.0.19041.0 

net6.0-windows10.0.19041.0 

someObject.As

• Если вы видите это исключение при использовании проекции C#/WinRT из компонента C++/WinRT, убедитесь, что компонент установил для свойства Windows Desktop Compatible значение True либо через свойства проекта, либо через файл .vcxproj .

Ошибки управления версиями пакета SDK для .NET

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

Сообщение об ошибке или предупреждающее сообщение	Причина
Предупреждение MSB3277. Обнаружены конфликты между различными версиями WinRT.Runtime или Microsoft.Windows.SDK.NET, которые не удалось устранить.	Это предупреждение сборки возникает при ссылке на библиотеку, которая предоставляет типы Windows SDK на своей поверхности API.
Ошибка CS1705: сборка «AssemblyName1» использует typeName, которая имеет более высокую версию, чем ссылка на сборку AssemblyName2.	Эта ошибка компилятора сборки возникает при указании и использовании типов Windows SDK, представленных в библиотеке.
System.IO.FileLoadException	Эта ошибка среды выполнения может возникнуть при вызове определенных API в библиотеке, которая не предоставляет типы Windows SDK.

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

Известные проблемы

Известные проблемы и критические изменения указаны в репозитории C#/WinRT в GitHub.

Если у вас возникли какие-либо функциональные проблемы с пакетом NuGet программы C#/WinRT, компилятором cswinrt.exe или созданными источниками проекции, сообщите нам о них на странице проблем с C#/WinRT.

Дополнительные ресурсы