Возможно, это далеко, но Blend нуждается в капитальном ремонте и в рабочем процессе, ориентированном на дизайн.

Конструктор XAML должен быть надежным и мощным.

Какой-то способ визуализировать многоуровневую структуру страницы / окна, что особенно важно с повышенными элементами управления.

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

Настройки управления дисплеем для CoreOS, Surface Phone, Surface Hub, Xbox, HoloLens выполняются самим дизайнером.

Комбинированные конструкторы для XAML, смешанные с WinForms, WPF, MFC и всеми другими платформами, с которыми будет работать WinUI Desktop.

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

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

Лучшие способы тестирования различного масштабирования DPI с помощью приложений, включающих WinForms, MFC и т. Д.

Шаблоны для новых элементов управления, настраиваемые словари ресурсов тем, интеграция редактора тем Fluent, шаблоны для поддерживаемых комбинаций приложений (Win32 MFC с пользовательским интерфейсом Xaml и т. Д.).

Шаблоны для точек интеграции оболочки, таких как средства выбора файлов, всплывающие окна панели задач.

Это всего лишь несколько мыслей ...

Мои мысли следующие:

1. С MSIX все хорошо, но я все еще использую старый добрый MSI для установки более сложных приложений, требующих функций, которые MSIX не поддерживает. Я также с подозрением отношусь к использованию MSIX из-за того, насколько дороги требуемые сертификаты Authenticode. (Я могу легко подписать свой код самозаверяющим сертификатом, который, по моему мнению, так же безопасен, как и сертификат, который я покупаю у фирмы, но тогда Windows не загрузит его. Однако Windows с радостью примет самозаверяющий файл MSI .) Пока я могу использовать WinUI 3 из приложения на базе MSI, я счастлив.
2. Мы были бы очень признательны за лучший конструктор XAML, но мне не нужна дополнительная сложность интеграции конструкторов WinUI XAML и WinForms / WPF в один. Я в полном порядке с переключением между разными вкладками в VS.
3. Как я отмечал ранее , отделение компилятора XBF от систем проектов C # и Visual Basic было бы очень полезно. (Было бы даже лучше, если бы был выпущен исходный код компилятора XBF или документация, достаточная для его воссоздания, но я не знаю, насколько вероятно это произойдет.)
4. Лучшая поддержка C ++ / WinRT и MIDL 3 в системе проектов C ++. В настоящее время проектная поддержка использования C ++ / WinRT хрупкая и неуклюжая. (Например, если вы измените пространство имен в файле IDL, что часто требуется, если в имени проекта есть точка, которую вы хотите использовать в пространствах имен, поскольку шаблон автоматически преобразует их в символы подчеркивания, ваш проект не сможет скомпилировать , и для решения проблемы, по моему опыту, требуется переместить файлы *.h и *.cpp сторону, восстановить их с нуля, скопировать код, а затем выгрузить и отредактировать файл vcxproj, чтобы исправить вложение.) Как бы мне ни хотелось использовать что-то более современное и гибкое, чем vcxproj, я не могу этого сделать из-за жесткой зависимости от него компилятора XBF.

Если появится что-нибудь еще, я обязательно опубликую это здесь. Спасибо!

1. Что мне интересно, так это ... Ну, мне нужно будет использовать префикс пространства имен, например < winui: Listview или < controls: listview, или что-то еще, что решат разработчики? Думаю, было бы намного лучше, если возможно, использовать тот же опыт, что и сейчас, просто Префикс - это нормально, и это здорово, всего для нескольких элементов управления. Но когда вы начинаете использовать повсюду, это делает чтение XAML кошмаром и очень.
   Не имеет смысла использовать префикс пространства имен, поскольку невозможно использовать Windows.UI.Xaml.Controls и WinUI будет выбором по умолчанию.

2. Прямо сейчас я даже не использую дизайнер XAML. Буквально отключаю в настройках. Конструктор XAML работает медленно и требует лучшей поддержки. Это было хорошо для WPF, но не для UWP, особенно если вы хотите делать адаптивный дизайн, работать со страницами, отображать данные и т. Д.
   Вероятно, это обратная связь для далекого будущего, но я думаю, что это хорошая обратная связь, на которую стоит обратить внимание. Конструктор WPF работает намного быстрее.
   Это из-за песочницы что ли?

3. Был бы интересен инструмент для миграции. Тем более, что у него может быть несколько проблем с совместимостью с обновленными элементами управления WinUI 3.0, такими как ScrollViewer. Поэтому, если есть инструмент, он должен хотя бы показывать возможные предупреждения об этих обновленных / переписанных элементах управления.

1. Нам нужен надежный редактор кода xaml с IntelliSense, отделенный от дизайнера.
   Большую часть времени я просто пишу код xaml, например C #. В настоящее время редактор кода медленный и хрупкий, как я объяснил в моем предыдущем комментарии . Работа с IntelliSense также довольно проста. Никакой быстрой информации о документации, никакого переименования участников.
2. Поддержка проектных данных для x:Bind может быть довольно сложной, поскольку я пишу сложный помощник в привязках функций. Но все может быть лучше, если встроенные функционалы xaml могут заменить некоторые помощники.
3. Мне нужно гораздо больше бесплатных комбинаций моделей упаковки для моих приложений. Может быть, не по теме, но я не могу найти нигде, чтобы оставить отзыв команде разработчиков приложения.

TL; DR Я хочу, чтобы модель приложения поддерживала сосуществование произвольных экземпляров . Даже одна и та же версия может работать с разными данными / набором параметров, например кусты Visual Studio. В настоящее время единственным решением является xcopy.

Кто-нибудь может сказать мне, как это свернуть?

Во-первых, я также использую приложение, которое разрабатываю ежедневно (и использую >> debug в течение большинства дней). Так что создание сосуществования сборки разработчика со стабильной сборкой мне очень поможет. В настоящее время мне нужно увеличить номер версии, упаковать отладочный msix, обновить установленную версию пакета для отладки.
На разных этапах отладки мне нужны разные возможности. Для сложных данных реального мира я хочу, чтобы экземпляр отладки делился данными со стабильным. Однако для произвольных фальшивых данных мне нужна изоляция. Теоретически это решается путем доступа к данным с помощью средства выбора папок, но очень жаль, что SQLite в UWP не поддерживает это, и, насколько мне известно, нет другого встроенного механизма ACID.

Да, и еще кое-что. Я был бы очень, очень, очень признателен, если бы можно было что-то сделать относительно того, как vcxproj требует использования packages.config для ссылок на пакеты NuGet. WinUI распространяется как пакет NuGet, как и C ++ / WinRT и другие ключевые компоненты. Мне действительно не нравится использовать packages.config. PackageReference намного эффективнее (и это не приведет к поломке сборки, если вы переместите vcxproj в другой каталог). Это действительно работает при использовании из vcxproj, если цель восстановления запускается в соответствующее время. (Это связано с тем, что цели vcxproj косвенно импортируют механизм восстановления PackageReference для проектов C #, не относящихся к SDK.) Я написал набор целей, которые автоматически запускают цель Restore при изменении набора элементов PackageReference, поскольку VS этого делать не будет. сам (пока). К сожалению, система NuGet ничего об этом не знает и поэтому пытается добавить файл packages.config, когда я добавляю шаблон файла C ++ / WinRT. Это вызывает разного рода хаос, в результате чего возникает исключение и поврежден файл проекта. Я не уверен, как лучше решить эту проблему, но я был бы очень признателен, если бы на это можно было хотя бы взглянуть до выпуска WinUI 3. Спасибо!

Было бы неплохо, если бы WinUI поддерживал новый проект sdk - Microsoft.NET.Sdk или MSBuild.Sdk.Extras .
Файлы csproj старого стиля сложно поддерживать. И мы не можем использовать с ним несколько TargetFrameworks , что может быть полезно для перехода на WinUI.

Почему нет поддержки F #?

Следует ли обсуждать здесь функциональность Azure DevOps и Visual Studio App Center?

Как и @vitorgrs , я предпочитаю собственные элементы управления без префикса пространства имен, это добавляет «шума» в код. И это помогает увидеть, какие элементы управления являются собственными, а какие - сторонними.

Конечно, было бы неплохо использовать инструмент миграции. Если он будет работать с крупными сторонними поставщиками (Telerik, DevExpress, ...), это уже будет иметь большое значение.

Шаблоны

Есть ли интерес / необходимость в том, чтобы предыдущие версии шаблонов XAML UWP оставались в потоке новых проектов VS?

С моей стороны шаблоны хранить не нужно. Но может ли быть, что в UWP есть элемент управления, которого нет в WinUI? Если это могло произойти, то это может быть веской причиной для создания традиционного приложения UWP и переноса его в WinUI, когда там есть требуемый элемент управления. Тогда может понадобиться шаблон.

Может быть, это также сбивает с толку разработчиков, если вы создали приложение и больше не можете создавать его с помощью последней версии Visual Studio.

Но лично мне неинтересно хранить шаблоны.

Как мы можем помочь вам добиться большей эффективности или успеха в отношении шаблонов и компонентов в Visual Studio?

На мой взгляд, это отлично подходит для UWP. Теперь я хочу увидеть то же самое для Win32. :)

Полезен ли этот обзор, и вы хотели бы видеть его больше по мере того, как сценарии обретают форму?

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

Миграция

Было бы полезно, если бы мы предоставили инструмент миграции, который автоматизирует шаги 1–3?

Определенно. Возможно, небольшое расширение Visual Studio будет отличным вариантом для этой миграции. Я также могу придумать что-то вроде «Анализатора совместимости WinUI», который выводит, что можно перенести, а что нет. Нечто похожее на анализатор переносимости .NET.

Какие библиотеки вы используете за пределами собственного набора элементов управления Windows 10?

Обычно Telerik DataGrid и Community Toolkit

Каким образом мы можем помочь с миграцией, о которой в настоящее время не думаем?

Если вы откроете приложение UWP в Visual Studio, имеющее более раннюю версию, чем установленный вами Win SDK, Visual Studio перенесет его за вас. Возможно, вам стоит подумать о чем-то подобном и для миграции WinUI. Я не уверен, но об этом нужно помнить. Особенно, когда в Visual Studio больше нет обычных шаблонов UWP, разработчиков может сбивать с толку наличие приложения, которое нельзя создать с помощью шаблона.

Другие

Как уже упоминалось в других комментариях, я думаю, что пора перейти на файлы .csproj в стиле SDK.

добавить шаблоны winui 3.0 в студию шаблонов Windows.

WinUI в настольных приложениях

WinUI in Desktop позволит разработчикам использовать библиотеку пользовательского интерфейса Windows в модели настольного приложения. @ marb2000 работает над более подробным обсуждением в ближайшие недели. Не стесняйтесь использовать эту ветку до тех пор для предложений.

Как разработчик .net, это то, что меня больше всего интересует.

Шаблоны

• Есть ли интерес / необходимость в том, чтобы предыдущие версии шаблонов XAML UWP оставались в потоке новых проектов VS?

В зависимости от количества шаблонов. Если число невелико (например, только «Пустое приложение (универсальная Windows)» для каждого языка, то есть 1 в случае c #), шум низкий и может поддерживаться. Но если в нем задействовано несколько шаблонов, не включайте их по умолчанию и добавьте дополнительный компонент установки VS, чтобы добавить их.

• Как мы можем помочь вам добиться большей эффективности или успеха в отношении шаблонов и компонентов в Visual Studio?

Держите настоящий пустой шаблон без строительных лесов (лучше для учебных пособий). Взгляните на то, что делает ядро ​​asp.net, есть много изменений, которые они внесли в свой новый опыт проекта. По сути, вы выбираете общий шаблон «Приложение (UWP WinUI)», затем второй экран, специфичный для вашей модели приложения, позволяет вам выбирать из разных шаблонов. Используйте этот шаг, чтобы также выбрать минимальную и целевую версию платформы (так что никаких дополнительных шагов). Вы можете добавить возможность, например, напрямую создать проект упаковки приложения.

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

• Полезен ли этот обзор, и вы хотели бы видеть его больше по мере того, как сценарии обретают форму?

да

Языковая поддержка

• Было бы полезно, если бы мы предоставили инструмент миграции, который автоматизирует шаги 1–3?

Достаточно хорошей документации (одна страница с четкими инструкциями). Если все можно сделать из VS без ручного редактирования csproj, я предлагаю добавить только страницу документации, описывающую шаги.

Если вы решите (и я надеюсь, что вы это сделаете) переключиться на новый формат csproj, тогда обязательно потребуется инструмент миграции, поскольку для миграции потребуется отредактировать файл csproj.

Упаковка

MSIX - это современный метод упаковки для всех приложений. Должны ли мы поддерживать ClickOnce для WinUI в Win32? Для каких еще методов упаковки мы должны включить поддержку? Специально для WinUI в Win32

Сравните различия между развертыванием clickonce и msix:

1. функция установщика приложений не предлагает такой же опыт в более старых версиях Windows
2. Для MSIX требуется действующий подписанный пакет (внутренний или общедоступный). Clickonce поддерживает самоподписанные пакеты.
3. модель пакета имеет некоторые ограничения, в основном вызванные изолированной средой (например, нет доступа к локальным данным приложения, нет операции с повышенными правами).

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

Трудно предвидеть все различия между этими двумя фреймворками, поскольку формат упаковки Appx часто рекламируется только для приложений, ориентированных на Магазин, и когда мы видим ограничения, мы не всегда знаем, применимы ли они также к формату распространения через Интернет.

• Дизайнерский опыт

Спектакли, выступления, выступления и поддержка крупных решений с большим количеством проектов.

Будет ли версия WinUI пакета SDK для Windows 10 и конструктор WinUI Xaml с открытым исходным кодом?

Сможем ли мы публиковать запросы на рабочий процесс и опыт разработки?

Будет ли SDK следовать той же периодичности выпуска, что и выпуски WinUI nuget?

Дополнительная боль:
улучшить отладку управляемого и неуправляемого микширования.
В настоящее время, когда исключение происходит в неуправляемом коде, COMException сайте управляемой отладки отображается
По сравнению с WPF стек управляемых вызовов всегда доступен, а выброшенное исключение содержит строку, полезную для отладки.
Я знаю, что неуправляемый мир и модель COM не так удобны, как управляемая. Но, по крайней мере, когда фреймворк генерирует исключение (ошибочный HResult), мне нужна необходимая информация, чтобы найти строку кода из репозитория с открытым исходным кодом. Способ может быть ручным, но должен быть детерминированным.

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

Что касается шаблонов, было бы неплохо иметь тот, который предоставляет шаблонный пользовательский интерфейс и код для NavigationView и навигации.

Спасибо

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

Что касается шаблонов, было бы неплохо иметь тот, который предоставляет шаблонный пользовательский интерфейс и код для NavigationView и навигации.

Спасибо

Наиболее распространенная структура и шаблоны «оболочки» приложения - должны быть доступны в виде шаблонов, чтобы разработчики могли быстро приступить к работе. Основные приложения Microsoft должны служить образцами в этих макетах и ​​действовать как передовой опыт с точки зрения поведения, согласованности и соблюдения норм проектирования пользовательского интерфейса для Fluent Design и WinUI.

@shaggygi @mdtauk
Для «структуры и шаблонов оболочки наиболее распространенного приложения» и «Что касается шаблонов, было бы неплохо иметь такую, которая предоставляет шаблонный пользовательский интерфейс и код для NavigationView и навигации». есть Windows Template Studio, которая поддерживается и разрабатывается как Microsoft, так и сообществом. Процитируем его введение:

Windows Template Studio (WTS) - это расширение Visual Studio 2017 и 2019, которое ускоряет создание новых приложений универсальной платформы Windows (UWP) с помощью мастера. Результирующий проект UWP представляет собой хорошо сформированный, читаемый код, который включает новейшие функции Windows 10 и реализует проверенные шаблоны и передовые практики.

@ Felix-Dev: Будут ли в конечном итоге шаблоны WPF в дополнение к UWP?

@shaggygi Может быть, для вас хорошие новости! См. Эту ветку : хотя, похоже, на данный момент ничего не гарантировано, идея предоставления шаблонов специально для проектов WPF, по-видимому, изучается. Как отмечено в связанной ветке, на Build 2019 был проведен закрытый сеанс быстрого ознакомления под названием «Windows Template Studio - WPF Edition».

Мы используем C ++ / WinRT. На данный момент мы не используем конструктор xaml или привязку. Но мы будем создавать элементы управления во время выполнения и стилизовать их, возможно, с помощью UWP xaml. Нам также потребуются диалоговые окна и немодальные дочерние окна с островами xaml, включая стыковочные / плавающие окна и т. Д.

Я пробовал писать XAML для своего приложения на C ++, и этот опыт был болезненным.

Мне пришлось добавить много недокументированных свойств проекта и несколько других уловок, чтобы все правильно сгенерировать и правильно упаковать.

Например:

• При создании проекта для хранения моих страниц XAML мне пришлось добавить <_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp> и <_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform> , два свойства проекта, которые полностью недокументированы и выясняются только путем проверки исходного кода нового терминала.
• У меня было загадочное сообщение «Не удалось создать новое представление, потому что главное окно еще не создано», пока я не создал и не использовал класс App, который в VS не существует, кроме создания нормальной страницы и перехода к свойствам XAML в VS и изменив его на определение приложения, а затем настроив MIDL, исходный код и файл XAML.
• Я добавил пакет NuGet Microsoft.Toolkit.Win32.UI.XamlApplication для создания своего класса приложения и не мог загрузить его, пока не добавил Microsoft.VCRTForwarders , опять же, я обнаружил это при проверке исходного кода Терминала, нигде нет никаких указаний ни на один из пакетов.
• PRI не объединялись в один, пока я не добавил что-то в файл .wapproj, поэтому он не смог найти мой ресурс XAML.
• XBF не работал, пока я не добавил <DisableEmbeddedXbf>false</DisableEmbeddedXbf> который неожиданно отключает встроенный XBF вместо его включения. Единственная ошибка, с которой я столкнулся, - это ошибка синтаксического анализа XAML, в которой ничего не указывало на то, что файлы XBF не работают.
• maxVersionTested в моем манифесте приложения полностью игнорировалось, пока я не изменил его на нижний регистр, хотя в инструкциях говорилось использовать версию с верблюжьим регистром: https://github.com/MicrosoftDocs/windows-uwp/issues/1781 #issuecomment -511173811

Кроме того, C ++ / WinRT также был занозой в заднице:

• Каждый раз, когда я запускал инкрементную сборку, у меня был [msg]redefinition [context]: MyClass для моих пользовательских классов, который не позволял мне создавать и не уходил, пока я не запустил чистую сборку, которая из-за заголовков C ++ / WinRT занимает много времени. Эта проблема каким-то волшебным образом исчезла на полпути.
• Теперь, когда я запускаю чистые сборки, я получаю сообщение об отсутствии заголовков. Нажав кнопку сборки во второй раз, она снова заработает.
• Мне пришлось написать свой собственный класс AppT<> из-за плохой генерации кода из C ++ / WinRT. Приложение «Терминал» и образец островов XAML делают то же самое, как если бы это было что-то, что пользователи должны были бы сделать, вместо того, чтобы устранить корневую проблему.
• Изменение чего-либо в файлах MIDL приводит к ошибкам сборки, пока я не сделаю чистую сборку.

Даже тогда он по-прежнему не работает в распакованном виде даже при добавлении материала activatableClass в мой манифест приложения (что-то о невозможности найти ресурс XAML, например, когда я не объединил PRI), что важно для поддержки моего приложения.

Миграция

Автоматизация для шагов 1-3 определенно полезна, особенно потому, что переименование пространств имен в сотнях файлов занимает очень много времени и подвержено ошибкам. Вдобавок ко всему, был бы хорош анализатор совместимости, такой же, как .net framework> .net core, который создает отчет о совместимости текущей кодовой базы и отмечает все возможные необходимые изменения.

Инструменты

Как уже говорили другие, было бы неплохо иметь редактор с более широкими возможностями. Большую часть времени здесь, на работе, XAML выполняется вручную и в основном используется конструктор в качестве руководства по грубому скелету того, как выглядит приложение. Intellisense и интеллектуальный рефакторинг были бы действительно полезны, такие вещи QoL, как CTRL + R + R для переименования вещей (например, свойств зависимостей или даже тега), например, особенно когда у вас есть много настраиваемых UserControls а также Реализация GoTo и ссылки. Также была бы хороша поддержка анализатора Roslyn.

Чтобы расширить возможности улучшения пространств имен. Было бы неплохо, если бы каким-то образом можно было упростить создание настраиваемых элементов управления без префикса, не добавляя новый XmlnsDefinition s в пространство имен по умолчанию, он убирает разметку imo и потребует префиксов только тогда, когда обнаруживаются неоднозначные элементы управления, как как работают классы, это также хорошо согласуется с реализацией GoTo. Обычно имени элемента управления и, возможно, наведения на него, чтобы показать полное пространство имен, было бы достаточно, чтобы знать, откуда он взялся, вы обычно не используете псевдонимы пространства имен ни в коде C #, если это не нужно.

В основном по инструментам, было бы неплохо, если бы он вел себя как редактор C #, чтобы сделать рефакторинг менее хрупким или хлопотным и упростить навигацию по разметке. Помимо этого, что касается самого языка XAML, уменьшение многословности было бы хорошим примером, например, стилизация, как обсуждалось в # 62 и # 279.

Чтобы расширить возможности улучшения пространств имен. Было бы неплохо, если бы каким-то образом можно было упростить создание настраиваемых элементов управления без префикса, не добавляя новый XmlnsDefinition s в пространство имен по умолчанию, он убирает разметку imo и потребует префиксов только тогда, когда обнаруживаются неоднозначные элементы управления, как и как работают классы, это также хорошо согласуется с реализацией GoTo. Обычно имени элемента управления и, возможно, наведения на него, чтобы показать полное пространство имен, было бы достаточно, чтобы знать, откуда он взялся, вы обычно не используете псевдонимы пространства имен ни в коде C #, если это не нужно.

Я хотел бы думать, что версия WinUI 3.0 элемента управления Page избавилась от необходимости использовать префикс для этих элементов управления. Я предполагаю, что это будет вещь уровня SDK.

Можно ли не менять пространства имен при использовании WinUI?

Одно исправление должно заключаться в том, что вы можете исключить ссылки Windows.UI.Xaml.* WinMD из build. Теперь цели сборки ссылаются только на Unified WinMD, также известную как. Windows.winmd , добавьте параметр в цели, чтобы также ссылаться на отдельные WinMD, таким образом, мы можем включать или исключать ссылки на основе приложения, которое мы создаем.

Так ли это, тогда нет необходимости изменять пространства имен, поскольку он ведет себя как .NET dll он может работать с перенаправлениями сборки на локальную версию внутри пакета, а не с системными.

Я знаю, что этот метод предназначен специально для .NET Framework, но для UAP должно быть решение для таких сценариев. Я знаю, что в манифесте msix/appx есть FrameworkDependency. Возможно, мы сможем использовать это, чтобы предоставить новому WinUI пространства имен Windows.* а не Microsoft.* .

Со стороны разработчиков у нас будет меньше проблем с обновлением наших приложений, поскольку мы меняем только ссылку, а не код !

Я бы предпочел вообще не менять пространство имен!

Преимущества:

1. Не нужно менять код туда и обратно.

2. После стабилизации локального кода WinUI вы можете снова выполнить слияние с платформой Windows, чтобы системные приложения и бизнес-приложения могли использовать преимущества новых улучшений в каждом новом выпуске Windows.

3. С одной стороны, это очень стабильная системная структура с высокой совместимостью, такая как .NET Framework. А с другой стороны, это похоже на .NET Core, с более быстрыми изменениями, со всеми преимуществами обоих и без каких-либо проблем.

Я бы не подумал, что нужно предоставлять инструмент для переноса. Это однократное изменение, достаточно простое с помощью функции «Найти и заменить», и количество экземпляров будет довольно низким.

Также возникли дополнительные проблемы:

• После добавления ресурсов в класс App мой XAML не мог найти его, пока я не добавил это, снова обнаруженное в приложении Terminal и не имеющее большого представления о том, что он на самом деле делает:
  xml <Target Name="PlaceAppXbfAtRootOfResourceTree" DependsOnTargets="GetPackagingOutputs"> <ItemGroup> <_RelocatedAppXamlData Include="@(PackagingOutputs)" Condition="'%(Filename)' == 'App' and ('%(Extension)' == '.xaml' or '%(Extension)' == '.xbf')" /> <PackagingOutputs Remove="@(_RelocatedAppXamlData)" /> <PackagingOutputs Include="@(_RelocatedAppXamlData)"> <TargetPath>%(Filename)%(Extension)</TargetPath> </PackagingOutputs> </ItemGroup> </Target>
• Сборка будет полностью прервана случайным образом с ошибкой, аналогичной cannot find type Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication и единственный способ восстановить сборку проекта - это выполнить чистую сборку.
• Я не могу запустить приложение, напрямую установив vcxproj для основного exe в качестве проекта запуска, мне нужно вручную запустить распакованный вывод appx в bin\x64\Debug\AppX а затем ввести отладчик из VS или установить пакет приложения как процесс запуска.

Связанные материалы по Windows Desktop: .NET Community Standup - 25 июля 2019 г., если интересно.

Давно WinForms, здесь разработчик WPF с некоторым опытом работы с UWP. Вот мои 2 цента:

Миграция

• Необходим инструмент для миграции существующих приложений UWP в WinUI.
• Инструмент для преобразования элементов управления WinForms или WPF в элементы управления WinUI в существующем приложении был бы просто потрясающим. Под преобразованием элементов управления я подразумеваю изменение ссылок в контейнере на отдельные элементы управления.
• Инструмент для миграции Xamarin Forms в WinUI, чтобы разрешить обратный перенос мобильного приложения на Windows.

Инструменты

• Текущий редактор XAML ужасен! Он должен использовать обычную основу текстового редактора и обеспечивать применение функций Roslyn к объектной модели XAML для улучшения интеллектуального анализа и рефакторинга.
• Пока Visual Studio не станет 64-разрядной версией, редактор XAML должен быть автономным 64-разрядным приложением за кулисами. Мне постоянно приходится перезапускать VS 2017 и VS 2019, чтобы избежать ошибки нехватки памяти при работе с большим количеством XAML.

Шаблоны

• Нам нужны эти шаблоны проектов

  • NavigationView WinUI
  • NavigationView WPF
  • Лента WinUI
  • Лента WPF
  • Лента WinForms

• Нам нужны эти шаблоны страниц / окон

  • Страница медиа-контроллера
  • Страница браузера
  • Диалоговое окно
  • Окно без полей
  • Плавающее окно

• Нам нужны шаблоны управления

  • Представление сетки инкапсулированных данных
  • Представление инкапсулированных дочерних данных

Эти два последних будут работать вместе, чтобы создать простые окна Master-Detail.

все эти шаблоны, страницы и т. д. уже создаются в проекте Windows Template Studio, почему бы не пойти по тому же маршруту вместо того, чтобы воссоздать все это?

Файл проекта стиля SDK
Один из наиболее важных моментов, который я хотел бы видеть - как уже упоминали многие другие, - это поддержка нового формата файлов проекта SDK Style для приложений UWP и Desktop XAML.

Миграция между UWP и моделями настольных приложений XAML
Если мы начнем создавать приложение «Desktop XAML», как далеко оно будет от приложения UWP? Будет ли впоследствии тривиально превратить его в приложение UWP, если мы поймем, что не выходили за рамки ограничений песочницы UWP? Или, если мы начнем создавать приложение UWP и осознаем, что нам нужно больше, будет ли легко превратить его в приложение «Desktop XAML»?

Я с поддержкой Template Studio.

Я с поддержкой Template Studio.

Поддерживает ли Template Studio проекты XAML C ++?

То, что делает Template Studio, должно быть частью WinUI SDK IMO.

То, что делает Template Studio, должно быть частью WinUI SDK IMO.

Должен быть частью Visual Studio IDE IMO! 😎

ребята, дело в том, что студия шаблонов Windows делает все в одном материале для создания проекта UWP, поэтому помня об этом, если чего-то не хватает, например, поддержки xaml C ++, мы должны подумать о добавлении этого в студию шаблонов Windows, я думаю, что это будет быстрее и больше эффективен, если все новшества в проектах uwp остаются в одном проекте.

Пусть будет какой-нибудь способ использовать нижний уровень стека WinUI 3 напрямую, без XAML или даже MVVM. Это особенно полезно для существующего программного обеспечения C ++ с большим железом, в кодовой базе которого уже есть какая-то архитектура MV-независимо. Им просто нужно что-то получше, чем HWND + GDI.

И, пожалуйста, заставьте людей подумать, что

@ be5invis Полностью согласен. Единственное решение на данный момент - XamlDirect, но оно больше ориентировано на разработчиков промежуточного программного обеспечения.

Вы уже можете вручную создавать контент с Xaml Islands. Просто заставьте DesktopWindowXamlSource работать и прикрепите к окну, а затем создайте и упорядочите / разместите элементы управления в коде.

https://gist.github.com/sylveon/5bc68b2801333b24f7b3165c3f098cc9#file -picker-cpp-L46

@MarkIngramUK Им может потребоваться что-то более «законченное», например, замена CreateWindow функциями WinUI.

В целях дизайна мне бы очень хотелось, чтобы в будущих шаблонах WinUI WPF была поддержка расширения содержимого страницы в заголовок, как в текущих приложениях UWP. Прямо сейчас, с существующим решением островов XAML, мы просто размещаем элементы управления внутри окна WPF / WinForms, а не в современном представлении.

@LucasHaines Список языков, которые мы планируем поддерживать с WinUI 3.0: C #, C ++ / WinRT, Visual Basic. Мы изучаем возможность поддержки F #.

Это показывает, что вы делаете это неправильно не только для F #, но и для всех языков .Net. Вы начинаете с размышлений о шаблонах и файлах .xaml, что похоже на постройку дома и установку ковров и занавесок на место, не завершив структуру.

У вас должна быть возможность установить WinUI в любой проект .Net Standard 2.0 / .Net Core 3.0 / .Net 5 как пакет Nuget. Тогда у вас будет доступ ко всем классам, определенным внутри. Затем вы можете ссылаться на такие проекты из проекта WinUI (который может быть только C #). Это позволяет создавать представления WinUI на любом языке .Net. Посмотрите, как это делает Xamarin.Forms .

Классы уже доступны для использования в F # (поскольку они являются компонентами среды выполнения Windows, которые могут использоваться всеми языками .NET).

Вы сможете создать макет вручную. Вы даже можете сделать это через Python, используя Py / WinRT для всех забот WinUI.

@sylveon Какие конкретно классы? Мне было бы интересно ...

Все они. Общедоступный API WinUI - это только компоненты среды выполнения Windows.

@LucasHaines Список языков, которые мы планируем поддерживать с WinUI 3.0: C #, C ++ / WinRT, Visual Basic. Мы изучаем возможность поддержки F #.

Это показывает, что вы делаете это неправильно не только для F #, но и для всех языков .Net. Вы начинаете с размышлений о шаблонах и файлах .xaml, что похоже на постройку дома и установку ковров и занавесок на место, не завершив структуру.

У вас должна быть возможность установить WinUI в любой проект .Net Standard 2.0 / .Net Core 3.0 / .Net 5 как пакет Nuget. Тогда у вас будет доступ ко всем классам, определенным внутри. Затем вы можете ссылаться на такие проекты из проекта WinUI (который может быть только C #). Это позволяет создавать представления WinUI на любом языке .Net. Посмотрите, как это делает Xamarin.Forms .

Эта тема / вопрос касается инструментов. Да, на библиотеки можно напрямую ссылаться с любого языка, способного их использовать, но есть размытие определений между инструментами и поддержкой языка.
В качестве примера возьмем Xamarin.Forms. Это предоставляет инструменты только для C # и, в меньшей степени, для F #. Можно создавать приложения с помощью VB.Net и Xamarin.Forms, но это не _официально поддерживается_, поскольку для этого нет инструментов и только ограниченная документация.

Кроме того, поскольку WinUI специфичен для Windows, на него нельзя ссылаться ни в одном проекте .Net Standard 2.0 / .Net Core 3.0 / .Net 5.
Также для некоторых сценариев требуется поддержка уровня проекта / компилятора / упаковки.

Отличная команда поработала над выпуском v2.2 . Есть ли шанс получить краткую информацию о статусе версии 3.0?

Я вижу, как об этом упоминалось несколько раз, но нет четкого направления в ту или иную сторону. Поскольку WinUI 3.0 теперь будет иметь все элементы управления, требование пространства имен для ссылки на элементы управления библиотеки WinUI ДОЛЖНО быть удалено. Это сильно загромождает XAML, сильно затрудняет миграцию и нарушает простую совместимость с такими вещами, как платформа UNO и Avalonia.

Удалите необходимость в xmlns:mux="using:Microsoft.UI.Xaml.Controls" из XAML. Я понимаю, что код позади все еще нужно изменить. Также может быть конфигурация для этого места в проекте.

Удалите необходимость в xmlns:mux="using:Microsoft.UI.Xaml.Controls" из XAML.

Это не потребуется в _markup_ XAML, но изменение пространств имен в коде программной части все равно потребуется.

Если вы хотите использовать элементы управления Windows (если они не удалены из ОС) - вам необходимо объявить пространство имен в XAML.

Если вы хотите использовать элементы управления Windows (если они не удалены из ОС) - вам необходимо объявить пространство имен в XAML.

С WinUI 3.0 это не сценарий - вы не можете смешивать и сопоставлять элементы управления ОС с элементами управления WinUI 3.0. Прямо сейчас это работает только с WinUI 2.x, потому что эти элементы управления являются надстройками к ОС (и у нас есть много неудобных случаев, когда мы отправляли тип в обоих местах, таких как NavigationView и TreeView, вызывая неоднозначность).

Если вы хотите использовать элементы управления Windows (если они не удалены из ОС) - вам необходимо объявить пространство имен в XAML.

С WinUI 3.0 это не сценарий - вы не можете смешивать и сопоставлять элементы управления ОС с элементами управления WinUI 3.0. Прямо сейчас это работает только с WinUI 2.x, потому что эти элементы управления являются надстройками к ОС (и у нас есть много неудобных случаев, когда мы отправляли тип в обоих местах, таких как NavigationView и TreeView, вызывая неоднозначность).

Рад слышать. Упростит отказ от этого в ОС. Я надеюсь, что приложение «Настройки», оболочка и другие части ОС также перейдут на WinUI 3.0.

И давайте надеяться на перенос средств администрирования, Wordpad и т. Д. На XAML с повторным использованием того же кода в максимально возможной степени!

@jevansaks Хорошо, понял, спасибо за отзыв!

@mdtauk Нет необходимости проводить различие между устаревшими элементами управления «ОС» и новыми элементами управления платформы «WinUI 3.0» в XAML. Все переходит на WinUI 3.0, а элементы управления ОС, как вы знаете, больше не получают обновлений. После WinUI 3.0, если разработчик по-прежнему хочет использовать устаревшие элементы управления, им следует разрабатывать с использованием более старых пакетов SDK и версий Visual Studio. Сохранение возможности ссылаться на две библиотеки элементов управления пользовательского интерфейса Microsoft / Windows из XAML было бы просто помехой по причинам, указанным ранее. Кроме того, с разделением WinUI разработка, наконец, может переключиться на устойчивый путь «разрешения» подобных изменений - что даже не является нарушением.

Изменить: забыл обновить перед ответом, большая часть этого сейчас избыточна.

@robloo Я рад, что это действительно заменит предыдущие версии UWP Xaml. Я также надеюсь, что ОС сможет перейти на нее для Inbox Apps и Shell.

Я также надеюсь, что будет множество видеороликов для разработчиков, в которых подробно описывается процесс перехода на WinUI 3.0 - и как работать с WinUI 3.0 с тем же жизненным циклом, что и приложения Win32. Больше никакой регидратации, лучшие способы сохранения состояния страницы и навигации и т. Д.

Было бы полезно (в зависимости от того, какие приложения планируют перейти на WinUI 3.0) предоставить примеры, например, использования Wordpad и переноса кода в новый пользовательский интерфейс, созданный в WinUI, а также взять приложение для входящих сообщений, такое как Groove Music, и переместить его. в WinUI 3.0

Для WinUI 3 должна быть некоторая последовательность в отношении размещения функций приложения на языке дизайна.

В связи с этим App Settings.

Где мне найти настройки приложения? Нажимать ли я шестеренку в правом верхнем углу? В нижнем левом углу? Могу ли я щелкнуть аватар профиля в правом верхнем углу и выбрать настройки? Я нажимаю в верхнем левом углу? Нижняя левая? Мне перейти в Edit> Preferences?

Действительно зависит от того, используете ли вы NavigationView ...

От: shaheedmalik [email protected]
Отправлено: четверг, 12 сентября 2019 г., 15:48:12
Кому: microsoft / microsoft-ui-xaml [email protected]
Копия: The Sharp Ninja [email protected] ; Комментарий [email protected]
Тема: Re: [microsoft / microsoft-ui-xaml] Опыт и инструменты разработчика WinUI 3.0 - требуются вводные данные (№ 1045)

Для WinUI 3 должна быть некоторая последовательность в отношении размещения функций приложения на языке дизайна.

В связи с этим App Settings.

Где мне найти настройки приложения? Нажимать ли я шестеренку в правом верхнем углу? В нижнем левом углу? Могу ли я щелкнуть аватар профиля в правом верхнем углу и выбрать настройки? Я нажимаю в верхнем левом углу? Нижняя левая? Мне перейти в Edit> Preferences?

-
Вы получили это, потому что прокомментировали.
Ответить на это сообщение непосредственно, просматривать его на GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049 или приглушить нить https: // GitHub. com / notifications / unsubscribe-auth / AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ .

Как мы можем помочь вам добиться большей эффективности или успеха в отношении шаблонов и компонентов в Visual Studio?

Чтобы заставить WinUI / XAML Islands работать с C ++ / WinRT в Visual Studio, не потребуются значительные усилия и недокументированные атрибуты конфигурации проекта.

Не могу переоценить это, но для меня важнее всего то, что WinUI обрабатывает больше, чем просто Windows.

Как только я увидел Surface Duo, мне стало интересно, какой будет история кроссплатформенной разработки теперь, когда Microsoft выпускает устройство на базе Android. Xamarin.Forms не сокращает его по ряду очевидных причин. Пришло время Microsoft полностью внедрить кроссплатформенный инструментарий (например, платформу UNO, но законченный и стабильный), который, как мы все знаем, запрашивался в различных формах в течение многих лет. Я надеюсь, что у Microsoft есть несколько недосказанных планов для разработчиков.

Сатья заявил: «Мы не хотели просто создать опыт и одно устройство, но оно охватывает все устройства в нашей жизни». Если вы хотите, чтобы разработчики участвовали в этой поездке, как надеется Панос, это лучший способ сделать это. В противном случае вы просите разработчиков написать два отдельных пользовательских интерфейса, чтобы охватить «взаимодействие» между Surface Duo и остальной частью семейства. Я не думаю, что это справедливый запрос к разработчикам в рамках одного «семейства» устройств.

Визуализируется по-разному на каждой платформе, иначе говоря, «естественный внешний вид».

Я этого не понимаю. Пожалуйста, не делайте этого, последнее, что я хочу, чтобы от Fluent Design было больше несогласованности, а не меньше.

РЕДАКТИРОВАТЬ: исходный комментарий удален

Сатья заявил: «Мы не хотели просто создать опыт и одно устройство, но оно охватывает все устройства в нашей жизни». Если вы хотите, чтобы разработчики участвовали в этой поездке, как надеется Панос, это лучший способ сделать это. В противном случае вы просите разработчиков написать два отдельных пользовательских интерфейса, чтобы охватить «взаимодействие» между Surface Duo и остальной частью семейства. Я не думаю, что это справедливый запрос к разработчикам в рамках одного «семейства» устройств.

ИМЕННО поэтому я был удручен тем, что Duo был Android.

Шаблоны должны быть с открытым исходным кодом, чтобы удалять любые возникающие в них проблемные области.

Когда я буду использовать WinUI с WPF и когда создам новый элемент управления с таким кодом, как:
c# public class MyControl : UserControl { ... }
Он будет использовать WinUI.UserControl или WPF.UserControl?
Придется ли нам выбирать и как с этим бороться?

И что интересно, если инструменты XAML будут унифицированы, сможем ли мы создавать какие-то общие файлы xaml?
Что-то вроде:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

Должен ли это быть какой-то общий диалект со специальным корневым пространством имен? (например, общие проекты в Visual Studio). Это может выглядеть как условный xaml.

Он будет использовать WinUI.UserControl или WPF.UserControl?
Придется ли нам выбирать и как с этим бороться?

Это должно происходить автоматически в XAML, где вы определяете

<UserControl 
   x:Class="MyApp.MyControl" 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Это сообщает компилятору, что это UWP.

public class MyControl : UserControl { ... }

На самом деле это неверно. Вы должны так заявлять

public partial class MyControl { }

Наследование не требуется, потому что оно обрабатывается файлом .g.cs, который определяет наследование, а также используемую структуру.

Что касается шаблонов, я был бы счастлив, если бы было больше, чем шаблон Hello World. Я имею в виду, что Microsoft должна создать резервную копию некоторых периферийных фреймворков, необходимых для работы с клиентскими приложениями.

@weitzhandler Я тоже хотел бы это увидеть !!

Проекты в стиле SDK для проектов C # и Cpp / WinRT также должны быть обязательными.

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

• Лента
• Главное меню
• Интерфейс документа с вкладками
• Просмотр навигации
• Команда / Панель инструментов
• Верхний вид навигации
• Хаб / Галерея (я знаю, что это немного устарело)
• Treeview / MasterDetails (проводник, RegEdit, приложение для администрирования)

Но также должны быть шаблоны элементов для общих диалогов, страниц, страниц настроек и т. Д.

Как мы можем помочь вам добиться большей эффективности или успеха в отношении шаблонов и компонентов в Visual Studio?

Работайте с расширением C ++ для VSCode / Visual Studio. Я также хочу видеть VS Code в качестве поддерживаемого редактора, который предоставляет возможности, аналогичные Visual Studio. Предполагается, что WinUI будет OSS, как и VS Code, поэтому я думаю, что это выполнимо.

Такие инструменты, как Template10 и Windows Template Studio, указывают на отсутствие базовой функциональности. В WinUI3 должна быть функциональность для того, что делают эти инструменты. Я держу пари, что многие разработчики делают эти базовые строительные леса снова и снова ... они должны быть частью фреймворка. Никаких дополнительных инструментов не потребуется. Возможно, вам даже придется отключить леса MVVM для тех редких случаев, когда вы хотите обойтись без него.

После работы с ASPNET Core мне не хватает внедрения зависимостей. Эта функция изначально присутствует в ASPNET Core. Это просто работает, без каких-либо дополнительных действий. И вы можете легко добавлять или изменять службы, если хотите. Но для сегодняшней UWP вам нужно создать это самостоятельно или использовать что-то вроде WTS, чтобы начать работу, но все равно кажется, что это приклеено потом. WinUI3 с правильным внедрением собственных зависимостей был бы очень полезен.

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

Такие инструменты, как Template10 и Windows Template Studio, указывают на отсутствие базовой функциональности.

Я рассматриваю такие вещи как расширение базовых функций. Конечно, такие вещи можно было бы принести в дом, но основная команда должна их поддерживать и поддерживать. По мере того, как основная команда делает больше, это, как правило, означает, что они распределяются более тонко, и поэтому все занимает больше времени. Если Msft считает, что у них есть бюджет, чтобы внести такие вещи в основную команду, я бы хотел поговорить с кем-нибудь об этом;)

Несколько мыслей об упрощенных стилях и шаблонах элементов управления, например о том, как упростить добавление настраиваемого поведения для встроенных стилей и элементов управления. Прекрасным примером здесь является стиль Button , когда нам нужно переопределить весь шаблон элемента управления, чтобы изменить цвет наведения или использовать радиус границы. Установка некоторых из них напрямую, например css , предотвратит создание километров кода XAML.

@AntiPasha Вы слышали о стиле в

Изменение цвета наведения для кнопки было бы просто:

            <Button Content="MyButton">  
                <Button.Resources>
                    <ResourceDictionary>
                        <ResourceDictionary.ThemeDictionaries>
                            <ResourceDictionary x:Key="Dark">
                                <SolidColorBrush x:Key="ButtonForegroundPointerOver" Color="Blue"/>
                                <SolidColorBrush x:Key="ButtonBackgroundPointerOver" Color="Transparent" />
                            </ResourceDictionary>
                        </ResourceDictionary.ThemeDictionaries>
                    </ResourceDictionary>
                </Button.Resources>
            </Button>

Свойство Control.CornerRadius также было добавлено в 17763 SDK, и команда WinUI также вводит переопределяемые ресурсы для простого добавления настроек приложения или всей страницы без изменения стиля элементов управления: https://github.com/microsoft/microsoft-ui- xaml-specs / blob / user / chigy / roundedcorner / active / RoundedCorner / roundedcorner.md # настройки -options

И что интересно, если инструменты XAML будут унифицированы, сможем ли мы создавать какие-то общие файлы xaml?
Что-то вроде:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

Должен ли это быть какой-то общий диалект со специальным корневым пространством имен? (например, общие проекты в Visual Studio). Это может выглядеть как условный xaml.

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

Мы можем использовать пространство имен по умолчанию, чтобы различать платформу «верхнего уровня», к которой принадлежит файл xaml, поэтому, например, мы могли бы иметь следующие пространства имен по умолчанию для каждой платформы XAML (они в основном гипотетические, поэтому воспринимайте их с некоторой долей скепсиса. 😄):

wpf: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
uwp: xmlns="http://github.com/microsoft/microsoft-ui-xaml"
авалония: xmlns="https://github.com/AvaloniaUI/AvaloniaUI"
uno: xmlns="https://github.com/unoplatform/uno"
xamarin.forms: xmlns="https://github.com/xamarin/Xamarin.Forms"

Итак, чтобы смешивать WinUI с WPF с использованием Xaml Islands, у вас есть разметка, которая выглядит следующим образом:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
                       xmlns:uwp="http://github.com/microsoft/microsoft-ui-xaml">
   <StackPanel>
     <uwp:Button Content="Hi, UWP!" x:Name="uwpButton">
     <Button Content="Hi, WPF!" Width="{x:Bind uwpButton.Width}" />
   </StackPanel>

</UserControl>

Что вы думаете?

@stevenbrix
В вашем примере для UWP будут отображаться обе кнопки, не так ли?
Я имею в виду, что на случай, когда xmlns = "... / xaml / presentation" является пространством имен верхнего уровня, а UserControl wutg StackPanel доступны как в uwp, так и в wpf, тогда разве вторая кнопка не будет доступна на обеих платформах?

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

Да, я полностью согласен с этим.

В вашем примере для UWP будут отображаться обе кнопки, не так ли?
Я имею в виду, что на случай, когда xmlns = "... / xaml / presentation" является пространством имен верхнего уровня, а UserControl wutg StackPanel доступны как в uwp, так и в wpf, тогда разве вторая кнопка не будет доступна на обеих платформах?

@Tirraon , приведенный мной пример предназначен исключительно для приложения WPF, которое использует острова Xaml для постепенной модернизации своего приложения. Он не предназначен для «стандартной» разметки, которая используется между приложениями WPF и WinUI, имеет ли это смысл?

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

Я разговариваю по телефону прямо сейчас, но я смогу получить более конкретную информацию о том, что я предлагаю, до и после, когда окажусь рядом со своим компьютером.

@stevenbrix
О, теперь я тебя понял, спасибо.

@stevenbrix
О, теперь я тебя понял, спасибо.

@Tirraon отлично! Рад, что мы на одной странице ☺️

Извините, если мне показалось, что моя идея возникла неожиданно, мы уже давно обсуждали, как мы потенциально можем объединить инструменты с целью улучшения сценария острова Ксамл. Как вы думаете, есть ли в этом ценность?

FWIW, я определенно думаю, что в том, что вы предлагали, есть достоинства. Но я пытаюсь сосредоточиться на том, что мы можем сделать в сроки WinUI3 / .NET5.

Выясните, как визуализировать WinUI Xaml в некотором конвейере, который переводит вывод на собственный холст и получает ввод от собственной системы сообщений. Как WinUi.Adapters.DirectX, WinUI.Adapters.WASM, WinUi.Adapters.X, WinUi.Adapters.Android.

При запуске не обязательно внедрять все адаптеры, только те, которые необходимы для поддержки Windows 10.

От: Стивен Кирбах [email protected]
Отправлено: четверг, 7 ноября 2019 г., 9:13:46
Кому: microsoft / microsoft-ui-xaml [email protected]
Копия: The Sharp Ninja [email protected] ; Комментарий [email protected]
Тема: Re: [microsoft / microsoft-ui-xaml] Опыт и инструменты разработчика WinUI 3.0 - требуются вводные данные (№ 1045)

@stevenbrix https://github.com/stevenbrix
О, теперь я тебя понял, спасибо.

@Tirraon https://github.com/Tirraon отлично! Рад, что мы на одной странице ☺️

Извините, если мне показалось, что моя идея возникла неожиданно, мы уже давно обсуждали, как мы потенциально можем объединить инструменты с целью улучшения сценария острова Ксамл. Как вы думаете, есть ли в этом ценность?

FWIW, я определенно думаю, что в том, что вы предлагали, есть достоинства. Но я пытаюсь сосредоточиться на том, что мы можем сделать в сроки WinUI3 / .NET5.

-
Вы получили это, потому что прокомментировали.
Ответить на это сообщение непосредственно, просматривать его на GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMXFLY#issuecomment-551121583 или отписки https://github.com/ уведомления / отписаться-auth / AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ .

Да, пожалуйста, сценарий острова XAML на данный момент ужасен

@sharpninja
Вы должны взглянуть на Уно
https://platform.uno/
Также он будет поддерживать WinUI 3.0 для каждой платформы.
https://platform.uno/winui-on-windows7-via-unoplatform/

@stevenbrix
Я не очень разбираюсь в Xaml Islands и обычно работаю с простым UWP. Но мне обязательно нужно посмотреть на это поближе.
Мое предложение не было связано с самим Xaml Islands, но больше касалось WinUI в целом, поскольку оно будет работать на нескольких платформах.

Мое предложение не было связано с самим Xaml Islands, но больше касалось WinUI в целом, поскольку оно будет работать на нескольких платформах.

@Tirraon , да, я полностью понимаю, и мне очень нравится твоя голова 🙌

Я кратко поговорил с @jeromelaban и компанией о том, что именно вы предлагаете, и определенно есть интерес. Пока нет конкретного плана или обязательств, так как мы все еще находимся на очень ранних стадиях обсуждения. Такой вклад полезен и помогает нам лучше понять ценность, которую он приносит нашим клиентам 😄

Под сценарием острова XAML я подразумеваю сценарий C ++. Список проблем, с которыми я столкнулся, см. В моих предыдущих сообщениях в этой ветке.

Да, пожалуйста, сценарий острова XAML на данный момент ужасен

Под сценарием острова XAML я подразумеваю сценарий C ++. Список проблем, с которыми я столкнулся, см. В моих предыдущих сообщениях в этой ветке.

@sylveon Я вижу ваши комментарии (ссылки ниже), и да, это звучит ужасно. Извините, что вы столкнулись с этим, я уверен, что мы сделаем это лучше.
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -513505038

Большая часть боли, с которой вы сталкиваетесь, связана с системой звукового проекта, и я знаю, что это то, что находится на радарах многих людей (хотя я довольно отстранен). Вы видели это видео, которое сделали несколько членов нашей команды по инструментам XAML? Эта ссылка должна начинать видео YouTube в момент, когда @ michael- hawker и знакомство с новым опытом Xaml Island. Мы определенно заботимся о C ++, но я не знаю, рассмотрели ли мы до сих пор только .NET или были ли улучшения и в C ++. Вероятно, они могли бы больше прокомментировать это.

Есть много вещей, которые сделают использование острова Ксамл простым и естественным. Аспект, о котором я говорю, заключается в том, что в настоящее время способ включения острова содержимого UWP в WPF выглядит следующим образом (из видео выше):

  <Grid>
   <xi:WindowsXamlHost InitialTypeName="UWP_XamlApplication.SamplePage"/>
  </Grid>

Я думаю, что мы можем сделать лучше, чем это, и предоставить что-то вроде этого:

  <Grid>
   <uwp:SamplePage />
  </Grid>

@stevenbrix

Я кратко поговорил с @jeromelaban и компанией о том, что именно вы предлагаете, и определенно есть интерес. Пока нет конкретного плана или обязательств, так как мы все еще находимся на очень ранних стадиях обсуждения. Такой вклад полезен и помогает нам лучше понять ценность, которую он приносит нашим клиентам.

Так много интереса! (Этот разговор всплывает повсюду) Если WinUI post 3.0 перейдет на кроссплатформенные реализации, у вас будет широкая поддержка со стороны разработчиков. Взгляните на обсуждение # 1461. В краткосрочной перспективе было бы замечательно использовать технологию Uno Platform для преобразования XAML / C # в HTML / WASM для запуска приложений UWP на всех платформах. В долгосрочной перспективе меня беспокоит влияние на производительность работы в Electron или браузере, и есть место для более эффективной архитектуры.

В итоге, я знаю, что сейчас все заняты WinUI 3.0. Но когда это закончится, было бы здорово, если бы мы подключили @jeromelaban , @ marb2000 , @jevansaks и другие, чтобы выяснить, как лучше всего выполнять рендеринг UWP повсюду. Это также было бы очень интересным обсуждением в сообществе на будущее.

WinUi - единственный разумный путь, ведущий к выживанию как Neo, так и Duo

От: robloo [email protected]
Отправлено: четверг, 7 ноября 2019 г., 12:00:07
Кому: microsoft / microsoft-ui-xaml [email protected]
Копия: The Sharp Ninja [email protected] ; Упомяните упоминание@noreply.github.com
Тема: Re: [microsoft / microsoft-ui-xaml] Опыт и инструменты разработчика WinUI 3.0 - требуются вводные данные (№ 1045)

@stevenbrix https://github.com/stevenbrix

Я кратко поговорил с @jeromelaban https://github.com/jeromelaban и компанией о том, что именно вы предлагаете, и определенно есть интерес. Пока нет конкретного плана или обязательств, так как мы все еще находимся на очень ранних стадиях обсуждения. Такой вклад полезен и помогает нам лучше понять ценность, которую он приносит нашим клиентам.

Так много интереса! (Этот разговор всплывает повсюду) Если WinUI post 3.0 перейдет на кроссплатформенные реализации, у вас будет широкая поддержка со стороны разработчиков. Просто посмотрите обсуждение на # 1461 https://github.com/microsoft/microsoft-ui-xaml/issues/1461 . В краткосрочной перспективе было бы замечательно использовать технологию Uno Platform для преобразования XAML / C # в HTML / WASM для запуска приложений UWP на всех платформах. В долгосрочной перспективе меня беспокоит влияние на производительность работы в Electron или браузере, и есть место для более эффективной архитектуры.

В итоге, я знаю, что сейчас все заняты WinUI 3.0. Но когда это закончится, было бы здорово, если бы мы подключили @jeromelaban https://github.com/jeromelaban , @ marb2000 https://github.com/marb2000 , @jevansaks https://github.com/jevansaks и другие к выяснить, как лучше всего выполнять рендеринг UWP повсюду. Это также было бы очень интересным обсуждением в сообществе на будущее.

-
Вы получаете это, потому что вас упомянули.
Ответить на это сообщение непосредственно, просматривать его на GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNI2QA#issuecomment-551193920 или отписки https://github.com/ уведомления / отписаться-авторизация / AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ .

WinUi - единственный разумный путь, ведущий к выживанию как Neo, так и Duo

Я склонен согласиться, но получаю один и тот же пользовательский интерфейс из приложения для Windows, работающего на Android и Surface Duo. При минимальном вмешательстве разработчика - это Святой Грааль.

Если у WinUI есть шанс стать основной платформой разработки и дать Windows шанс не стать в долгосрочной перспективе просто вместилищем приложений других платформ. (Не всегда плохо, когда дело доходит до крупных устоявшихся приложений, но для LoB и следующих крупных приложений ...)

Я создаю свой собственный ориентированный на приложения язык и хочу поддерживать использование WinUI с XAML и свой язык для кода программной части. Было бы хорошо, если бы инструментальные средства предлагали возможность языка обеспечивать генерацию кода для XAML. Что было бы еще лучше, если бы генератор кода XAML построил IL как частичный класс, который можно было бы завершить с использованием любого языка. Это означало бы, что генератор кода будет выводить компилируемую сборку IL.

Я создаю свой собственный ориентированный на приложения язык и хочу поддерживать использование WinUI с XAML и свой язык для кода программной части. Было бы хорошо, если бы инструментальные средства предлагали возможность языка обеспечивать генерацию кода для XAML. Что было бы еще лучше, если бы генератор кода XAML построил IL как частичный класс, который можно было бы завершить с использованием любого языка. Это означало бы, что генератор кода будет выводить компилируемую сборку IL.

Есть XAML Direct, но на данный момент он поддерживается C # и C ++.
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

Это не то, что я имею в виду. Я имею в виду, что вывод инструмента генерации кода должен быть IL, а не C # или C ++. Таким образом, мой компилятор может преобразовать XAML в IL, а затем унаследовать этот класс.

@sharpninja Было бы также полезно, если бы он также мог генерировать байт-код LLVM вместо простого кода C ++.

Таким образом, мы можем объединить его с MIDL и XLang для создания библиотеки COM и файлов WinMD для использования во всех поддерживаемых XLang сценариях.

С моей шляпой по C ++, что я хотел бы видеть в инструментах WinUI для C ++, было бы, чтобы Microsoft наконец догнала то, что C ++ Builder делал с середины 90-х.

Предоставьте актуальные инструменты RAD для разработки на C ++.

C ++ / CLI этого не добился, хотя с формами можно было обходиться.

Казалось, что C ++ / CX будет правильным, но для этого потребовалось немного больше усилий, чем то, на что способен C ++ Builder.

Теперь C ++ / WinRT может быть стандартным C ++ 17, но общий опыт для разработчиков настольных ПК ощущается как понижение версии с увеличением количества шаблонов, которые приходится писать вручную, дополнительным вниманием к тому, как типы COM выходят за границы ABI, и отсутствием конструктора. служба поддержки.

Так что я пока все еще использую C ++ / CX, так как не чувствую, что могу иметь дело со всем шаблоном, требуемым компилятором MIDL, и поддержкой COM ABI.

С другой стороны, в моей шляпе .NET я хотел бы, чтобы библиотеки C ++, такие как DirectX, наконец были представлены в качестве компонентов WinUI, некоторые любят Blend и помнят, что F # якобы также является языком .NET от Microsoft.

Мне было очень трудно переключиться на WinUI. Существует ряд как собственных, так и сторонних библиотек, которые в настоящее время не используют WinUI, и их зависимости становятся проблематичными. Например, Behaviors SDK.

Эта идея возникла у меня, когда я говорил о StatusBar в Discord сообщества UWP ..

В Visual Studio включите в наборе инструментов записи для элементов управления WPF, которые отсутствуют в UWP, и когда эти записи выбраны, покажите всплывающее окно, объясняющее, как имитировать традиционный элемент управления.

Эта идея исходит из желания облегчить переход для людей, пришедших из WPF (или других фреймворков), где они ожидают увидеть определенные элементы управления, и отсутствие этих элементов управления может вызвать раздражение. Как узнать, что CommandBar можно использовать как StatusBar? Я думаю, нам нужно максимально упростить переход людей на WinUI. Это может помочь заполнить некоторые пробелы без необходимости разработки всех недостающих элементов управления.

РЕДАКТИРОВАТЬ:
И для полноты, вот еще кое-что, что я сказал о строке состояния ... просто показано, как кто-то может подойти к UWP (или WinUI), если они не знакомы с ним ...

Re: StatusBar - я думал с точки зрения пользователей традиционных фреймворков, пробующих UWP - и увидел, что у него нет StatusBar - по-прежнему является основным продуктом во многих приложениях. Да, CommandBar может быть даже лучше. Но люди не знают, что такое CommandBar, или могут догадаться, что это что-то еще. Кто-то из вышеупомянутых даже предложил мне добавить сетку, поместить ее внизу, сделать на одну строку выше и добавить различные элементы управления для отображения материала. Похоже, что даже существующие дизайнеры Xaml не знают о CommandBar. В любом случае, может быть, вы правы, может быть, CommandBar лучше, но Пол Туррот не использовал его в своем приложении блокнота UWP, он использовал сетку. Похоже, CommandBar не используется в качестве замены StatusBar. Обычные (или новые) разработчики все еще ищут StatusBar и не находят его. Я знаю, что Пол Туррот не разработчик, но вы меня поняли.

Было бы здорово, если бы в xaml также вводились фрагменты с обычным вариантом использования.

От: Гэвин-Вильямс [email protected]
Отправлено: вторник, 18 февраля 2020 г., 19:05:39
Кому: microsoft / microsoft-ui-xaml [email protected]
Копия: The Sharp Ninja [email protected] ; Упомяните упоминание@noreply.github.com
Тема: Re: [microsoft / microsoft-ui-xaml] Опыт и инструменты разработчика WinUI 3.0 - требуются вводные данные (№ 1045)

Эта идея возникла у меня, когда я говорил о StatusBar в Discord сообщества UWP ..

В Visual Studio включите в наборе инструментов записи для элементов управления WPF, которые отсутствуют в UWP, и когда эти записи выбраны, покажите всплывающее окно, объясняющее, как имитировать традиционный элемент управления.

Эта идея исходит из желания облегчить переход для людей, пришедших из WPF (или других фреймворков), где они ожидают увидеть определенные элементы управления, и отсутствие этих элементов управления может вызвать раздражение. Как узнать, что CommandBar можно использовать как StatusBar? Я думаю, нам нужно максимально упростить переход людей на WinUI. Это может помочь заполнить некоторые пробелы без необходимости разработки всех недостающих элементов управления.

-
Вы получаете это, потому что вас упомянули.
Ответить на это сообщение непосредственно, просматривать его на GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF6O3Y#issuecomment-587982703 или отписки https://github.com/ уведомления / отписаться-авторизация / AD3GCLFLGA773XOS5OSG5ULRDSAWHANCNFSM4ICOLUJQ .

История разработчика должна включать своего рода список сравнения.

Понятия, присущие приложениям Win32, например, строки состояния, панели инструментов, меню, захваты, вкладки и т. Д. В одном списке, а эквиваленты WinUI - в другом.

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

Открытый вопрос (ы)
Было бы полезно, если бы мы предоставили инструмент миграции, который автоматизирует шаги 1–3?

да. Я поддерживаю 1 «устаревшее» приложение Windows Forms (устаревшее означает отсутствие бюджета на переписывание) и 2 или 3 устаревших приложения WPF. Приложение WinForms может зависнуть, но инструмент, который поможет быстро перенести приложения WPF на WinUI 3, будет отличным!

MSIX - это современный метод упаковки для всех приложений. Должны ли мы поддерживать ClickOnce для WinUI в Win32? Для каких еще методов упаковки мы должны включить поддержку? Специально для WinUI в Win32

В настоящее время мы используем ClickOnce для публикации приложений на рабочих столах наших пользователей. По-прежнему желательна некоторая модель автоматических обновлений.

@JeffSchwandt

Эти шаги касались преобразования проектов WinUI, использующих более ранние версии (1-2), в версию 3.

Преобразование приложения WPF в приложение WinUI не особенно возможно в автоматическом режиме (без огромных усилий, но даже в этом случае это будет чрезвычайно подвержено ошибкам).

Я надеюсь, что это правильная ветка, чтобы опубликовать этот запрос.

Rust сейчас отчаянно нуждается в правильной структуре пользовательского интерфейса. Было бы хорошо, если бы WinUI мог поддерживать Rust в будущем с помощью собственного SDK и некоторых инструментов.

Я надеюсь, что это правильная ветка, чтобы опубликовать этот запрос.

Rust сейчас отчаянно нуждается в правильной структуре пользовательского интерфейса. Было бы хорошо, если бы WinUI мог поддерживать Rust в будущем с помощью собственного SDK и некоторых инструментов.

Хорошие новости, Rust / WinRT находится в стадии разработки, что позволит приложениям Rust использовать WinRT API, такие как WinUI! Взгляните на https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/

@jevansaks Привет, спасибо за ответ! Да, я знаю, что Кенни работает с Rust / WinRT, но мне интересно, является ли WinRT единственным уровнем API, который будет поддерживать WinUI? Я не уверен, как это согласуется с тем фактом, что использование WinRT API из настольных приложений стало доступно только в Windows 10 1903, в то время как WinUI нацелен на поддержку более старых версий Windows 10.

Rust / WinRT (например, C ++ / WinRT) должен работать вплоть до Windows 7. Сам WinRT всегда работал с настольными / win32-приложениями. Только определенные API-интерфейсы имеют требования store / uwp / Packaging (не WinRT в целом). Пока WinUI не имеет этих требований, вы сможете использовать WinUI из настольных приложений через C ++ / WinRT и Rust / WinRT на любой поддерживаемой платформе.

Настольные приложения WinUI должны поддерживать живые плитки и обновление плиток - с хорошими простыми примерами и инструментами SDK, чтобы создавать плитки проще, чем в современных приложениях UWP.

Я не уверен, как это согласуется с тем фактом, что использование WinRT API из настольных приложений стало доступно только в Windows 10 1903

WinUI Desktop сейчас разрабатывается для WinUI 3.0, и это должно позволить обычным приложениям Win32 использовать WinUI нижнего уровня (текущий план сокращен до 1803).

Пользовательский интерфейс Windows должен поддерживать как минимум основные фреймворки MVVM - MVVM Light, Prism и Caliburn. К сожалению, ваша задокументированная проблема с изменениями в INotifyPropertyChanged и INotifyCollectionChanged нарушает ObservableCollectionбезусловно, ломает MVVM Light и, вероятно, две другие структуры. Думал, тебе следует знать.

К сожалению, ваша задокументированная проблема с изменениями в INotifyPropertyChanged и INotifyCollectionChanged, нарушающими ObservableCollection, безусловно, нарушает работу MVVM Light и, возможно, двух других фреймворков. Думал, тебе следует знать.

Спасибо @terrycox! Нам известно, и эта проблема будет решена в WinUI 3.0 RTM, а в идеале - в предварительной версии до этого момента;)

@terrycox Windows UI должен поддерживать как минимум основные фреймворки MVVM - MVVM Light, Prism и Caliburn. ... ваша задокументированная проблема

Да, он должен исправить задокументированные проблемы, но нет необходимости в библиотеке пользовательского интерфейса .Net, включая WinUI, для поддержки инфраструктуры MVVM. Ему нужно только поддерживать объекты, представляющие элементы пользовательского интерфейса. .Net MVVM или реактивный фреймворк - это способ создания и изменения объектов .Net, представляющих пользовательский интерфейс, на основе объектов, представляющих данные. Ни одному из них не нужно знать о другом. Любой фреймворк можно комбинировать с любой библиотекой пользовательского интерфейса.

но нет необходимости в библиотеке пользовательского интерфейса .Net, включая WinUI, для поддержки инфраструктуры MVVM.

Но такие вещи, как события и интерфейсы, о которых известно UIElements, необходимы, и это то, что сломалось.

От: Чарльз Родди [email protected]
Отправлено: среда, 25 марта 2020 г., 14:28:46
Кому: microsoft / microsoft-ui-xaml [email protected]
Копия: The Sharp Ninja [email protected] ; Упомяните упоминание@noreply.github.com
Тема: Re: [microsoft / microsoft-ui-xaml] Опыт и инструменты разработчика WinUI 3.0 - требуются вводные данные (№ 1045)

@terrycox https://github.com/terrycox Пользовательский интерфейс Windows должен поддерживать как минимум основные фреймворки MVVM - MVVM Light, Prism и Caliburn. ... ваша задокументированная проблема

Да, он должен исправить задокументированные проблемы, но нет необходимости в библиотеке пользовательского интерфейса .Net, включая WinUI, для поддержки инфраструктуры MVVM. Ему нужно только поддерживать объекты, представляющие элементы пользовательского интерфейса. .Net MVVM или реактивный фреймворк - это способ создания и изменения объектов .Net, представляющих пользовательский интерфейс, на основе объектов, представляющих данные. Ни одному из них не нужно знать о другом. Любой фреймворк можно комбинировать с любой библиотекой пользовательского интерфейса.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104 или откажитесь от подписки https://github.com/notifications/unsubscribe-auth/ AD3GCLASFGPUSCRG5PFKOOTRJJLO5ANCNFSM4ICOLUJQ .

Инструменты Dotnet cli следует использовать вместе с файлом. Чистое ядро ​​sdk.
Команд, таких как dotnet new и dotnet build, должно быть достаточно, без жесткой зависимости от установки Visual Studio. Пожалуйста, полностью присоединяйтесь к эре .Net Core!

• Будет хорошо, если дизайнер xaml будет быстрым. Текущий конструктор XAML работает медленно и всегда выдает ошибку, говоря, что произошло какое-то исключение, и это не сработает. Исправьте это и предоставьте надежного дизайнера.

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

• Моя проблема объяснена

По строкам комментария @JensNordenbro , есть ли шанс, что это будет работать только с Vs Code?

Я хотел бы увидеть шаблон приложения, который создает приложение .NET 5 с пользовательским интерфейсом WinUI 3.0, которое ссылается на приложение хоста хранилища .NET 5. Это позволит уменьшить количество избыточных установок .NET 5.0.

Как в настольном приложении WinUI перейти от muxc.Window.ThisPtr к hWnd к собственному окну Win32?

Я только что попробовал новые шаблоны от мая 2020 года для WinUI 3 Preview 1 for Desktop, так как мне нравится эта идея.

Но у меня есть один вопрос. Поскольку WinUI является собственной платформой пользовательского интерфейса в Windows, я удивлен отсутствием связи, чтобы он действительно был частью Windows 10?

В результате получилось приложение Hello World размером около 120 МБ. Конечно, место дешево, но здесь у меня не было никаких зависимостей. Из них WinUI занимал значительный объем места, примерно столько же, сколько сам включенный .NET 5. Это только для сборки x64. Включите x86 в многоплатформенный пакет и удвойте его размер. Добавьте к этому несколько других зависимостей, и мы можем легко найти приложение размером 300 МБ, которое нужно упаковать для распространения.

Почему WinUI 3 не просто часть Windows версии .NET 5? Является ли это частью усилий по модульности .NET Core? Но если нет, то где ему место? Действительно коварная папка каждого приложения? В качестве официального пользовательского интерфейса Windows 10 ...?

Или он станет частью Windows 10 в будущем? Если бы WinUI больше рассматривался как системная библиотека, а .NET 5 начал бы поставляться с Windows позже, мы бы вместо этого рассматривали сравнительно крошечные приложения. Но, надеюсь, это именно та история, по крайней мере, для Windows 10X, а, может быть, позже и для Windows 10 без X? За исключением этих двух библиотек, а также DLL-моста Windows 10 SDK C # / WinRT, размер приложения резко падает до 1–5 МБ.

@ryandemopoulos заявил в Discord, что WinUI будет поставляться как пакет фреймворка, поэтому приложения, использующие Store или MSIX для распространения, не должны будут иметь свою собственную версию WinUI, поскольку все они будут использовать одну и ту же копию.

Если сделать WinUI частью самой Windows, то это решит проблему отделения WinUI от ОС.

«Надежно доступно и не в размере приложения» - вот что вызывает беспокойство. Я надеюсь, что .NET 5 распространяется аналогичным образом.

@lmcdougald Я приглашаю вас открыть вопрос в .NET Core Installer и попросить .NET 5 также использовать Framework Packaging для обслуживания.

@jonasnordlund есть еще одно обсуждение № 2500, в котором мы говорим о развертывании WinRT Runtime. Возможно, вы найдете там ответ. :)

@ marb2000 Я открыл вопрос, но, честно говоря, сбит с толку. Разве это не считается важным для любого приложения, которое будет поставлять Windows 10X?

Вот компиляция нескольких функций, некоторые из которых не являются непосредственно WinUI, но их отсутствие напрямую влияет на опыт разработки любого клиента .NET, включая клиенты UWP и особенно клиенты приложений LoB.

• Для меня в первую очередь важно развивать платформу Uno. Для меня это то, что делает UWP актуальным, я бы пошел на компромисс с XF или другой технологией, если бы Uno не было рядом. (https://github.com/microsoft/microsoft-ui-xaml/issues/2024)
• Абстрактный API управления идентификацией на стороне клиента, который будет использоваться из ViewModel (https://github.com/microsoft/ProjectReunion/issues/31)
• Полная поддержка аннотаций данных, проверки и заголовки пользовательского интерфейса, длина строк, обязательные атрибуты, поля только для чтения, водяные знаки и т. Д. И т. Д. И т. Д. (Https://bit.ly/3gcMJ3a)
• Улучшите OData, чтобы он стал подходящей альтернативой тому, что раньше было службам RIA. Например: поддержка создания атрибутов, реализации интерфейсов, общие типы, XML-документы (https://github.com/OData/odata.net/issues/1746)
• Добавьте все недостающие функции из WPF
• x:Bind также должен иметь все функции, которые есть в Binding , такие как области действия или вложенные привязки (https://github.com/microsoft/microsoft-ui-xaml/issues/2237)
• Горячий перезапуск (https://github.com/microsoft/ProjectReunion/issues/44)
• Больше, чем простые шаблоны Hello World. Например, такие, которые подходят для входа в систему, MVVM, маршрутизации, проектов x-plat (таких как Uno-Platform) и т. Д. Другими словами, пожалуйста, дайте больше возможностей WTS.
• Функции макета XAML WYSIWYG-редактора, такие как WinForms, такие как стыковка, интервал и т. Д. - похоже, это завершено! ❤

Спасибо за подборку @weitzhandler , очень удобно.

Команда WinUI поддерживает прекрасные отношения с группой разработки продуктов Uno (не Microsoft), командой Xamarin Forms / MAUI и React Native. Мы активно с ними сотрудничаем и желаем им успешного будущего.

Что касается недостающих функций WPF, не могли бы вы перечислить свои основные, пожалуйста? Устранение разрыва между WPF и WinUI - одна из наших целей. Однако потребуется несколько релизов.

По поводу более сложных шаблонов. У Window Template Studio есть эта миссия.

Я сделал проблему, чтобы попытаться собрать области, в которых не хватает WinUI по сравнению с WPF # 719 @weitzhandler @ marb2000

По поводу более сложных шаблонов. У Window Template Studio есть эта миссия.

@ marb2000, можем ли мы

По поводу более сложных шаблонов. У Window Template Studio есть эта миссия.

@ marb2000, можем ли мы

👀 @crutkas @sibille

Я предлагаю потратить некоторое время на C ++ Builder (VCL / FMX) и Qt Creator / Design studio, чтобы узнать, что возможно с C ++ и современными инструментами.

В идеале WinUI предлагал бы аналогичные инструменты для этих продуктов, которые уже сегодня используются для кроссплатформенных графических интерфейсов, написанных на C ++.

Что меня волнует, так это опыт разработки .NET и аналогичный опыт для случаев использования, которые я вынужден использовать C ++, которые по какой-то причине недоступны для нас.

C ++ Builder и QtCreator достигают такого опыта, и было бы приятно, если бы разработчики .NET чувствовали себя как дома, столкнувшись с необходимостью потратить пару дней на написание кода C ++ / WinRT.

Зачем так говорить о .NET-разработчиках? Опыт работы с C ++ XAML просто плох, не имеет значения, являетесь ли вы разработчиком C ++ или .NET.

Я считаю, что будет здорово, если они откроют дорогу для включения того же XAML, работающего на настольных компьютерах, в Интернете (Edge), на мобильных устройствах и в Интернете вещей.

Когда мы сможем использовать WinUI 3 в проекте на C ++ без C #, Xaml или дизайнера?
также есть ли какие-нибудь новости о дате открытия исходного кода ядра c ++ WinUI 3?

Изменить: я думаю, что получил ответ на свой первый вопрос, похоже, что в WinUI 3.0 Preview 1 есть шаблон проекта c ++ WinUI 3 :

После установки расширения .vsix вы можете создать новый проект WinUI 3.0, выполнив поиск по запросу «WinUI» и выбрав один из доступных шаблонов C # или C ++.

Вариант использования, который я хотел бы улучшить в WinUI, - это создание небольших инструментов на основе графического интерфейса для сотрудников службы поддержки ИТ, которые часто пишутся на PowerShell. Было бы здорово иметь возможность создавать такие инструменты в Visual Studio Code. Даже вариант разработки VSCode на основе C # был бы отличным шагом. Полноценная Visual Studio в этом случае кажется довольно сложной и сложной.

В настоящее время вместо этого в корпоративных средах используются такие инструменты:

• https://poshgui.com/ (веб-мастер XAML)
• Sapien PowerShell Studio 2020 (собственный)
• Редактор сценариев администратора (ASE) (сейчас заброшенный проект)

Другие часто используемые шаблоны «использовать Visual Studio для XAML» описаны здесь:

• Создайте простой графический интерфейс для сценария PowerShell
• Как создать графический интерфейс PowerShell для ваших скриптов

Мой вопрос связан с вопросом

In a WinUI desktop application, how does one go from muxc.Window.ThisPtr to an hWnd to the native Win32 window?

Поскольку это настольное приложение, мы не можем использовать ICoreWindowInterop, и я пробовал рандомизированные swags, такие как new HandleRef(this, ThisPtr) где 'this' имеет тип Microsoft.UI.Xaml.Window, но продолжаю видеть ошибку для Invalid Window Handle. Как только я наконец получу этот hwnd, я могу попытаться использовать больше COM, чтобы изменить стиль окна и поделиться им с другими, чтобы они не чувствовали боли, которую я делаю прямо сейчас :).

Для всех, кто интересуется, это быстрый подход, который я использовал для получения hWnd для главного окна, чтобы я мог сделать его без полей. Полное решение для WPF, эквивалентного WindowStyle = None, находится здесь .

using var process = Process.GetCurrentProcess();
var hWnd = process.MainWindowHandle;

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

Я думаю, что термины UWP и Universal Windows должны исчезнуть. Условия несут в себе досадный багаж, который заставляет разработчиков уклоняться.

Может быть, мы могли бы заменить шаблон WinUI (Universal Windows) на WinUI (Win64)? Тогда есть выбор: рабочий стол или магазин?

Win64 сбивает с толку - это означало бы, что Win32 API поддерживает только 32-битные, и, наоборот, UWP поддерживает только 64-битные, оба из которых ложны.

Само по себе название Win32 уже сбивает с толку множество новичков, нам не нужен Win64, чтобы усугубить ситуацию.

@VagueGit кое-что, что я узнал, заключается в том, что выбор правильного имени и создание истории - одна из самых сложных вещей. Лучше, чем заменять имя, мы (Microsoft) должны предоставить правильный продукт (и историю), чтобы помочь вам добиться успеха. UWP - это хорошо известная терминология Win32, поэтому мы должны продолжать их использовать.

Это наш подход (очень упрощенный):

WinUI можно использовать в двух «типах» приложений, предназначенных для разных устройств:

• Ваше приложение предназначено для множества устройств с большим количеством входов и форм-факторов. Затем используйте UWP. Для этого была создана UWP; следовательно, вы должны соответствовать таким требованиям, как модель упаковки, магазин, модель приложения, контейнер безопасности и т. д.
• Ваше приложение предназначено только для настольных компьютеров и требует полного доступа к ОС. Используйте Win32 или Desktop (так Visual Studio называет WPF, WinForms, MFC, приложениями).

WinUI в приложениях UWP и WinUI в классических приложениях (или

@ marb2000 Называть вещи сложно, согласен. Но некоторые имена, к сожалению, токсичны, и их следует оставить. Поэтому время от времени происходит ребрендинг продуктов. UWP - одна из них, но это только мое мнение ... и все, с кем я общаюсь. Но вот и все.

У нас есть приложение UWP, которое мы хотим перенести на WinUI. Мы не используем Win32 api, мы ориентируемся только на рабочий стол и не хотим использовать магазин. Как это подходит?

@ marb2000 Называть вещи сложно, согласен. Но некоторые имена, к сожалению, токсичны, и их следует оставить. Поэтому время от времени происходит ребрендинг продуктов. UWP - одна из них, но это только мое мнение ... и все, с кем я общаюсь. Но вот и все.

У нас есть приложение UWP, которое мы хотим перенести на WinUI. Мы не используем Win32 api, мы ориентируемся только на рабочий стол и не хотим использовать магазин. Как это подходит?

Для кого конкретно это приложение?

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

Не волнуйся, @shaheedmalik, мы не будем просить тебя трогать его :-). Пишем бизнес-приложения. Win32 и UWP. У нас есть приложение UWP, которое находится в магазине несколько лет, но его не видно в магазине. У нас есть налаженная база бизнес-клиентов, насчитывающая 30 лет. Они довольны нашим приложением UWP, но недовольны работой магазина, поэтому мы убираем его из магазина.

Итак, мы знаем, что существует рынок бизнес-приложений Win64, и считаем, что мы одни из немногих бизнес-разработчиков, которые предоставили приложения Win64, за которые бизнес-клиенты будут платить. Я знаю, что в этой теме есть несколько разработчиков, которые идут по пути Universal Windows / multi-platform, но они довольно редки. По моему опыту, большинство бизнес-разработчиков ориентируются на конкретный форм-фактор.

Итак, если говорить с точки зрения компании-разработчика, которая вложила значительные средства в UWP и добилась успеха в бизнесе с помощью UWP, может быть, шаблоны для WinUI (Desktop) и WinUI (Store)? Вам нужно только следить за техническими СМИ, чтобы понять, насколько плохо UWP рассматривается как платформа для разработчиков.

@VagueGit
«У нас есть приложение UWP, которое мы хотим перенести на WinUI. Мы не используем Win32 api, мы ориентируемся только на рабочий стол и не хотим использовать магазин. Как это подходит?»

Итак, вы хотите перенести UWP на WinUI 3 и развернуть его вне Магазина? Наивный вопрос: вы пробовали боковую загрузку от MSIX? Есть ли причина, по которой вы не пользуетесь UWP, помимо Магазина?

@VagueGit
«Итак, мы знаем, что существует рынок бизнес-приложений Win64».

Один вопрос, Win64 означает множество вещей. например, приложения компилируются для x64. Что для вас Win64?

@ marb2000 UWP плохо поддерживает бизнес-отчеты. Мы думаем, что ребрендинг может помочь дать толчок развитию сторонних инструментов, таких как составители отчетов. У нас была игра с боковой загрузкой, но это было невозможно для нас до 20H1, поскольку боковая загрузка не была включена по умолчанию.

Мы думаем, что Win64 - это путь вперед в Windows. В прошлом Micro $ безуспешно пыталась продвигать Win32 как наследие, и теперь возвращается на эту позицию. Но в конечном итоге Win32, по нашему мнению, должен уйти (я говорю это после 30 лет разработки Win32). Нам удалось преодолеть большинство ограничений UWP, чтобы предоставить бизнес-приложение, которое будут покупать компании. Мы обеспокоены тем, что еще одна итерация UWP будет иметь ограниченную популярность без ребрендинга.

Как показывает путаница из @ marb2000 , термин Win64 уже (плохо) используется. Я также указывал на это ранее.

Я согласен с тем, что может потребоваться ребрендинг, но Win64 - ужасный способ сделать это. Пока не появится что-то официальное, вы должны использовать термин UWP, чтобы его понимали все.

Все понимают, что

WinUI (Store) не подходит, потому что вы также можете отправлять приложения Win32 в магазине или отправлять приложения UWP за пределами магазина. Однако WinUI (Desktop) хорош.

@sylveon WinUI (Store) не препятствует другим проектам, ориентированным на магазин. Это просто означает, что вы хотите начать с набора возможностей, которые позволяют выпускать через магазин.

Это достаточно плохо, чтобы сбить с толку новичков.

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

Я никогда не зацикливаюсь на том, что что-то названо. Меня волнует только то, какие функции он имеет и насколько хорошо он поддерживается.

Я бы сказал, что есть также много разработчиков (включая меня), которые воодушевляются, когда мы здесь говорим о таких терминах, как MAUI, но сразу же разочаровываются, когда понимаем, что это все та же кодовая база. Ребрендинг предполагает: «Послушайте, мы создаем эту совершенно новую вещь, которая начинается с базы кода, которая полностью отличается от той, которая заблокировала вам доступ к xyz». Что мне нравится видеть, так это огромный список функций, которые изменили те проблемы смещения, которые были у меня или у кого-либо еще.

Платформы развиваются со временем, как и любой продукт или бренд. Меня утешают бренды и названия, которые существуют уже несколько десятилетий, потому что это автоматически подразумевает LTS. Хотя я действительно понимаю, что изменение имен иногда является необходимостью, они также напоминают разработчикам о том, что их бросили (Silverlight). Существует множество моделей автомобилей, которые в течение многих лет сталкивались с проблемами, но в итоге стали любимыми и уважаемыми брендами. Обо всем этом можно многое сказать, даже если вам не нравится предыдущий опыт, потому что вы знаете, чего ожидать. Пока проблемы решены, это действительно важно.

Я думаю, что необходимо рассмотреть как минимум две аудитории; разработчиков и конечных пользователей продукта. Как разработчик / владелец бизнеса, если у меня есть заказчик, которому нужно приложение, и его испортили названия базовых технологий, моя работа - внушить им уверенность в том, что продукт, представленный этим названием, созрел и что их беспокоит в будущем. прошлое было обновлено. С другой стороны, если я скажу: «Посмотрите, есть эта новая замечательная вещь под названием WinUI или MAUI», и они уже владеют продуктами WPF, UWP или Xamarin, которые мы для них разработали, их ожидаемый ответ: «О, отлично, теперь наши приложения написаны в 2, 3 или 4 различных технологиях ». Это то место, где я должен их продать. Учитывая, что все клиенты разные, я столкнусь с возражением, оставите ли вы имя как есть или измените его.

В конечном итоге (для меня) важно то, что у нас есть инструменты, необходимые для написания привлекательных, многофункциональных приложений с LTS. Я взволнован, когда вижу, что срок выполнения продукта достигает крайних сроков, и я могу прочитать список новых функций и решений проблем, когда продукт будет выпущен. Мне нравится это в NetCore / Net5 (изменение имени LOL) с 2016 года. (Кстати, пытаться сказать моим клиентам, что .Net5 - это то, на что мы планируем нацеливаться через год после того, как я убедил их перейти на NetCore, тоже непросто!)

Прямо сейчас я просто хочу перемотать вперед к моменту, когда я смогу написать настольное приложение с диалектом XAML и получить ту же производительность рендеринга, которую предлагает UWP / WinUI (без песочницы UWP). По этой причине и из-за того, что превью на сентябрь упало, я собираюсь начать тест-драйв Авалонии. Мне нравится сходство с WPF, когда я слышу о производительности рендеринга через SkiaSharp.

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

Я вас всех ценю.

Я понимаю, что пишет jtbrower в своем электронном письме. Его компания, подобная нашей, одна из немногих, которая успешно пошла по пути xaml. Нас не нужно убеждать в преимуществах.

Но как бы хорошо это ни было, xaml стал катастрофой для Micro $. В подавляющем большинстве разработчики либо остались с WinForms, либо полностью перешли на веб-разработку. После UWP отток разработчиков ухудшился.

Чтобы технологии xaml были устойчивыми, Micro $ должна привлечь миллионы разработчиков, которых им не удалось привлечь. Для этих разработчиков, поставщиков инструментов и технических СМИ UWP - тупик. Еще одна итерация UWP их не победит.

@VagueGit, но разработчики достаточно заинтересованы в том, чтобы знать, что переименованный продукт такой же. Они знают MAUI как переименованные Xamarin Forms. На самом деле они, кажется, заходят так далеко, чтобы сказать, что имя MAUI было украденным. Я не думаю, что вы можете мотивировать типичного разработчика сменой имени. Нам всем нужны функции, не так ли? Разве вы не предпочли бы, чтобы UWP разрешал несколько Windows или допускал полное доверие? Если бы они сделали и то, и другое, мы все могли бы нацеливаться на UWP и, возможно, сохранить песочницу для приложений магазина. Я просто вслух мечтаю, что бы меня действительно возбудило! Функции!!

Абсолютно согласен с вами jtbrower. Я также ценю вашу помощь и надеюсь, что другие критикуют их идеи. Но как сообщить разработчикам и поставщикам инструментов, что существует два разных UWP: Store и Desktop?

Так что непременно те, кто хочет продолжить путь UWP, могут начать с шаблона магазина UWP, но те, кому нужен 64-битный рабочий стол, а не песочница и полное доверие ... ну, это не UWP, не так ли?

UWP рассматривается на рынке как искалеченный. Все, кроме нас, стойких приверженцев, отказались от UWP, когда сама Micro $ отказалась от создания собственных приложений на UWP.

Рынок разработчиков не следит за развитием UWP. 64-битный рабочий стол, без песочницы и полного доверия, - это гораздо больше, чем смена имени; это другая парадигма. Но если он по-прежнему будет называться UWP, он останется незамеченным для тех, кто отказался от UWP.

@VagueGit Я рад, что вы добились успеха с UWP. Именование сложно, и тот факт, что мы называем это «универсальной платформой Windows», и это не совсем приемлемо для подавляющего большинства разработчиков Windows, делает его, ну, ну, не очень «универсальным». Точное резюме Project Reunion призвано исправить это и сделать каждый аспект UWP действительно доступным для всех разработчиков Windows.

Я согласен с тем, что UWP имеет плохую репутацию. Если вы введете фразу «UWP is» в поисковую систему, первое автоматическое предложение, которое вам выдаст Bing или Google, будет «UWP is dead». Однако я считаю, что @ marb2000 прав в том, что мы должны продолжать использовать это имя, несмотря на то, что он несет с собой.

С учетом сказанного ...

Сегодня многие аспекты проектов Desktop смогут использовать разные части того, что мы раньше определяли как «UWP»:

1. Стек пользовательского интерфейса (он же WinUI3)
2. Упаковка MSIX
3. Ресурсы MRT

После отмены CoreApplication единственной разницей между UWP и Desktop действительно будет модель песочницы, которую вы выберете для своего приложения, и на какие устройства вы сможете настроить таргетинг.

Мы обсудили внесение изменений в шаблоны проектов и использование мастера, который более точно описывает это.

@JeanRoca - руководитель

Мне нравится идея шаблона WinUI Desktop. Более подходящий, чем Win32, и перспективный. Мы бы начали с этого шаблона, тогда как Win32 предлагал 32-битное ограничение. Мы надеемся, что WinUI Desktop получит популярность в средствах массовой информации и среди разработчиков.

Когда приложение UWP выпускается за пределами магазина, используется пакет .appinstaller. Если мы обновим это приложение до Win UI Desktop, пакет установщика изменится с appinstaller на msix.

Предполагая, что мы сохраним детали в пакете приложения одинаковыми и соответствующим образом увеличим версию, распознает ли Windows, что это новая версия того же приложения, и сохранит ли локальные данные, или она установит его как другое приложение?

Насколько я понимаю, WinUI 3.0 никогда не будет использоваться из .NET Framework <= 4.8. Итак, если мы говорим о WinUI, мы говорим либо о .NET Native, либо о .NET 3.1 / 5 + (или другом наборе привязок).

Любые предложения относительно того, как продвигаться / спрашивать об упаковке фреймворка для .NET 5 (или, я думаю, 6 на данный момент)? Я открыл вопрос и не получил ответа. Объединение встроенного .NET 5 в пакет не запускается.

@stevenbrix

После отмены CoreApplication единственной разницей между UWP и Desktop действительно будет модель песочницы, которую вы выберете для своего приложения, и на какие устройства вы сможете настроить таргетинг.

К сожалению, еще одно большое отличие состоит в том, что разработчики .NET вынуждены переходить на C ++ для таких API, как DirectX, команда которых явно отказывается сделать их совместимыми с UWP, несмотря на то, что они основаны на COM.

И в процессе возврата к дням продуктивности ручного написания MIDL с помощью удобного блокнота и копирования файлов, очевидно, команда Windows не может отказаться от ATL, подобного опыту разработчиков, вместо того, чтобы предоставить NET-подобный опыт для рабочих процессов C ++. C ++ / CX становился слишком закрытым для C ++ Builder, поэтому его пришлось убить во имя ISO-материала, чтобы, если повезет, мы могли получить их в C ++ 23 и в 2025 году в VS.

Я сомневаюсь, что к тому времени кто-то будет интересоваться UWP, если не будет создан надлежащий опыт разработки, чтобы устранить все эти нарушения.

Также нас беспокоят проблемы с GitHub относительно того, какой команде дать отзыв - это очень быстрый способ потерять интерес. Я просто, очевидно, слишком сильно забочусь.

API-интерфейсы DirectX не могут быть изменены для совместимости с WinRT, потому что это будет серьезным нарушением API для существующих потребителей, а этого просто не может произойти.

Для DirectX доступно несколько управляемых оболочек, таких как TerraFX, которая является необработанной привязкой 1: 1, или Vortice, которая является оболочкой API в стиле C #.

Что касается CX, то его пришлось уйти. Расширения языка, специфичные для компилятора, плохи и не одобряются. Это значительно затрудняет переносимость кода, часто отстает с точки зрения поддержки стандарта C ++ и требует полной вертикальной интеграции с существующими библиотеками. Альтернатива, WRL, была очень сложной в использовании и слишком многословной. Поэтому неудивительно, что многие люди (включая подразделение DX) не хотели писать API WinRT.

C ++ / WinRT - гораздо лучшее решение, к сожалению, ему пришлось вернуть IDL (но в настоящее время это необходимое зло). Команда C ++ выполняет гораздо лучшую работу по поддержке стандартов, чем раньше, поэтому не будет ничего удивительного, если мы действительно получим метаклассы до того, как C ++ 23 будет завершен, что должно радикально улучшить UX разработчика.

@sylveon

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

То же самое происходило с CX ... он в основном не использовался, потому что разработчики C ++ не любят проприетарных языковых расширений.

Предполагая, что мы сохраним детали в пакете приложения одинаковыми и соответствующим образом изменим версию, распознает ли Windows, что это новая версия того же приложения и сохранит ли локальные данные, или она установит его как другое приложение?

@VagueGit , это отличный вопрос. В конце концов, технология установки приложений UWP и Desktop одинакова. Я чувствую, что да? Я думаю, что что касается более свежих SDK, даже приложения UWP имеют расширение .msix (я могу ошибаться, поэтому не цитируйте меня). Я уверен, что вы могли бы попробовать это на месте и узнать? @adambraden для fyi.

Любые предложения относительно того, как продвигаться / спрашивать об упаковке фреймворка для .NET 5 (или, я думаю, 6 на данный момент)? Я открыл вопрос и не получил ответа. Объединение встроенного .NET 5 в пакет не запускается.

@lmcdougald Думаю, я знаю, о какой проблеме вы говорите (но я не могу ее найти). Будет один, но я предполагаю, что он будет в период .net6. Все знают, что это нужно делать.

И в процессе возврата к дням продуктивности ручного написания MIDL с помощью удобного блокнота и копирования файлов, очевидно, команда Windows не может отказаться от ATL, подобного опыту разработчиков, вместо того, чтобы предоставить NET-подобный опыт для рабочих процессов C ++. C ++ / CX становился слишком закрытым для C ++ Builder, поэтому его пришлось убить во имя ISO-материала, чтобы, если повезет, мы могли получить их в C ++ 23 и в 2025 году в VS.

Также нас беспокоят проблемы с GitHub относительно того, какой команде дать отзыв - это очень быстрый способ потерять интерес. Я просто, очевидно, слишком сильно забочусь.

@pjmlp Я ценю вашу честность и страсть. Я не могу полностью согласиться с тем, что текущий опыт работы с C ++ не на высоте. Мы сделали немало вещей, чтобы сделать работу с C ++ более похожей на .NET, но, как упомянул @sylveon , они имеют свою цену. В конце концов мы решили, что если мы хотим потратить инженерные усилия на то, чтобы сделать C ++ великим, мы должны вложить их в продвижение стандарта C ++. Очень жаль, что мета-классы - это выход, и мы обсуждаем способы улучшить опыт в промежуточный период, потому что я согласен с вами, что мы не можем ждать так долго.

Спасибо за ответ - я доволен тем, что «все знают, что это нужно сделать», и я проживу с раздутым двоичным кодом в течение года или около того.

@stevenbrix и @VagueGit - вы все равно сможете использовать файл appinstaller для своих пакетов msix. файл appinstaller - это не что иное, как файл json, предоставляющий uri для ваших пакетов. Поскольку вы упомянули корпоративные сценарии, вы можете настроить uri установщика приложений соответствующим образом для внутренних расположений или сделать их разными для внешнего доступа - все зависит от вашего CDN. Что касается управления версиями - да, для упакованных приложений, если идентификатор пакета такой же, то при установке новой версии будет доступ к существующим данным приложения.

@stevenbrix @VagueGit Я отвечу, предоставив информацию о мастере, которая у меня сейчас есть, как о моем опыте. Я все еще новичок в этой роли, поэтому не стесняйтесь воспринимать все, что я говорю, с недоверием. С учетом сказанного, моя команда в настоящее время направляет усилия на Windows Template Studio . Это приложение в настоящее время позволяет создавать новое приложение WPF или UWP из существующих шаблонов в нашем мастере со страницами и фреймворками, которые вам нужны.

Цель и текущий план этого приложения на будущее - унифицировать и улучшить опыт разработки для всех пользователей. Мы в настоящее время разрабатываем шаблоны для настольных приложений с WinUI 3. Вы можете найти проблему отслеживания здесь . Мы также обсуждаем то же самое для UWP, чтобы наши пользователи могли легко перенести свои проекты, когда придет время. Мы до сих пор не знаем точно, как это сработает, но нашей целью будет максимально унифицировать и упростить опыт. Надеюсь, это поможет!

То же самое происходило с CX ... он в основном не использовался, потому что разработчики C ++ не любят проприетарных языковых расширений.

Они любят их на clang, GCC, Intel. xlCC, PGI, CUDA, C ++ Builder и множество других встроенных платформ.

Очевидно, CX был убит из-за политики, которая не может принять среду C ++ RAD от Microsoft, и вместо этого мы все делаем MDIL / ATL с помощью блокнота.

Я избегаю их любой ценой, независимо от компилятора. Особенно, если упомянутое проприетарное расширение само по себе является совершенно другим языком.

Я избегаю их любой ценой, независимо от компилятора. Особенно, если упомянутое проприетарное расширение само по себе является совершенно другим языком.

Тогда зачем кодировать собственный пользовательский интерфейс, такой как WinUI, вместо этого просто использовать открытые стандарты, такие как X Windows.

... как будто это можно использовать в Windows. Я избегаю расширений компилятора, потому что хочу использовать многоцелевые компиляторы (Clang и MSVC) для проверки соответствия стандартам и хочу использовать новые стандарты C ++.

В моем коде используется C ++ 20. Многие языковые расширения не поддерживают C ++ 17 или получили ее очень поздно. Эта ситуация повторится с C ++ 20 (или ухудшится, поскольку в C ++ 20 намного больше нового, чем в 17). Например, вы не можете смешивать C ++ 20 ( /std:c++latest ) и CX ( /ZW ), вы получите ошибку компилятора о несовместимости двух переключателей.

Только в этом году NVCC поддержала C ++ 17 на стороне устройства. Не очень хороший вид.

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

По указанным выше причинам я их избегаю. Если мы вернем опыт разработчика WinUI C ++ к языковому расширению, я перейду к альтернативной среде графического интерфейса.

@sylveon Вы идеально переносимый C ++ 20 для WinUI совершенно бесполезен за пределами Windows, развлекайтесь и с Qt без расширений.

Потому что для пользователей настольных компьютеров C ++ не остается ничего стоящего.

Спасибо, что подтвердили, что бессмысленная политика убила CX.

Предложение быть дружелюбными друг к другу. Я не могу комментировать технические аргументы C ++ и не буду судить, кто прав.
Дело в том, что такие фразы, как go have fun with X , не создают здесь дружеской атмосферы сотрудничества. @stevenbrix и другие, пожалуйста,

Спасибо @hansmbakker ☺️

@pjmm и @sylveon Я ценю страстный и честный разговор, здорово, что такие клиенты, как вы, заботятся.

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

@pjmlp нас не удовлетворяет текущий опыт работы с c ++, и мы понимаем, что нам нужно что-то сделать до метаклассов c ++. У нас было несколько дискуссий о c ++ / winrt без idl, и @kennykerr и @ Scottj1s рассказали об этом Build. Большинство проблем, которые у нас были, были связаны с интеграцией с WinUI, так как нашему компилятору требуются метаданные. Мы хотим вернуться к этому рабочему процессу, чтобы увидеть, сможем ли мы составить связную историю, которая улучшит общий опыт разработчиков. Вместо того, чтобы возвращать C ++ / Cx, заинтересовала бы вас версия c ++ / winrt без idl?

Просто чтобы установить ожидания, я бы не ожидал увидеть здесь большой прогресс в 2020 году.

Я был бы очень заинтересован в C ++ / WinRT без IDL.

Опыт IDE тоже не самый лучший. Например, мы не можем создать обратный вызов события из редактора XAML, как мы можем с C # (раскрывающийся список создания нового обратного вызова ничего не делает). Переход к определению из редактора XAML также не работает.

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

@stevenbrix , я хотел бы добавить свой голос к C ++ / WinRT без IDL (и, конечно, не хочу видеть возврата к C ++ / CX). Мы пишем кроссплатформенное программное обеспечение и компилируем как с MSVC, так и с LLVM (в том числе в Windows), поэтому для нас очень важен C ++, соответствующий стандартам.

@stevenbrix ,

@pjmlp нас не удовлетворяет текущий опыт работы с c ++, и мы понимаем, что нам нужно что-то сделать до метаклассов c ++. У нас было несколько дискуссий о c ++ / winrt без idl, и @kennykerr и @ Scottj1s рассказали об этом Build. Большинство проблем, которые у нас были, были связаны с интеграцией с WinUI, так как нашему компилятору требуются метаданные. Мы хотим вернуться к этому рабочему процессу, чтобы увидеть, сможем ли мы составить связную историю, которая улучшит общий опыт разработчиков. Вместо того, чтобы возвращать C ++ / Cx, заинтересовала бы вас версия c ++ / winrt без idl?

Просто чтобы установить ожидания, я бы не ожидал увидеть здесь большой прогресс в 2020 году.

Это просто показывает, насколько плохой была вся эта идея с C ++ / WinRT с самого начала, обрушив ее на нас, не принимая во внимание падение нашей производительности.

Для сравнения: давний разработчик, чей опыт разработки Windows восходит к Windows 3.0, и в настоящее время C ++ в основном актуален для использования вместе с приложениями на основе .NET, а не сам по себе.

Инструменты Borland были моим хлебом с маслом, пока по разным причинам, известным старым разработчикам Windows, дальнейший путь не закончился переходом на компиляторы Microsoft.

Visual C ++ никогда не был _Visual_ как C ++ Builder, даже с C ++ / CLI, учитывая отсутствие интеграции с формами и компиляцией AOT.

C ++ / CX казалось, что Microsoft наконец-то это получила, и 25 лет спустя нам будут предоставлены те же рабочие процессы производительности, что и при использовании Delphi / C ++ Builder вместе друг с другом.

Вместо этого мы получили политический ход, направленный на уничтожение C ++ / CX, не обращая внимания на нашу продуктивность, размахивая ответственностью за недостающие функции перед ISO C ++ и WG 21, как будто все, что команда Visual C ++ отнимает у нас, будет принято WG 21.

И даже если необходимые функции в конечном итоге будут приняты ISO C ++, это будет 2023, 2026, ....? И тогда возникает весь вопрос, когда эти функции действительно станут доступными для разработчиков Windows, просто посмотрите на поддержку модулей. У нас уходит около бесконечных лет, чтобы достичь паритета с тем, что предлагает нам C ++ / CX с момента выхода Windows 8 в 2012 году.

Так что, учитывая, что к 2020 году мы не увидим никаких улучшений, мы уже говорим о 9 годах здесь, так что извините, если я склонен немного возмущаться тем, как все это было решено, помимо других проблем, которые у нас есть. чтобы справиться с отказом UWP, Reunion, перезагрузкой экосистемы .NET, в то время как нас просят кодировать, как будто это был 2000 год, с голым опытом работы с блокнотом MIDL и бесконечным супом из шаблонов, таким как ATL.

Так что да, либо версия C ++ / WinRT без IDL, либо, по крайней мере, опыт IDL с полной поддержкой Intellisense / Intelicode и без необходимости вручную копировать файлы. Однако это не отнимет у самого кода C ++ опыт, подобный ATL.

С точки зрения разработки .NET / C ++ меня не волнует путешествие во времени в прошлое фреймворков Microsoft, а скорее то, как это могло бы выглядеть, если бы точка зрения C ++ RAD была воспринята более серьезно, к сожалению, с тем, как C ++ / История WinRT была управляемой, и все остальное, что сейчас происходит с отказом от UWP, интересно, куда делись «разработчики, разработчики, разработчики».

Прошу прощения, если это все еще кажется немного чрезмерным, но именно так я отношусь к падению моей производительности, когда мне нужно перейти с .NET на C ++, во имя некоторой чистоты ISO, которую большинство компиляторов C ++ все равно не делают.

C ++ по-прежнему актуален как автономный. Многие приложения написаны на чистом C ++ без запуска какого-либо управляемого кода. Фактически, вся среда выполнения UWP и среда XAML / WinUI - это собственный C ++. Приложение UWP, написанное на C ++, не имеет (к счастью) никакого управляемого языка.

Я бы сказал, что если вы чувствуете необходимость перейти на C ++ в .NET, вы должны спросить себя, почему, и попытаться решить эти проблемы непосредственно в .NET. Представление? Используйте встроенные типы span, stackalloc и vector. DirectX, собственные API или COM? Используйте привязку типа TerraFX. Взаимодействие только с библиотекой C ++? Реализуйте то, что вам нужно, в .NET.

.NET лучше без C ++, а C ++ лучше без .NET.

Я не думаю, что шаблоны в cppwinrt настолько плохи. Что меня больше всего раздражает, так это потребность в генерации кода и ужасное время компиляции, которое он производит.

@sylveon Easy, из-за API-интерфейсов, которые команда Windows отказывается предоставлять в качестве UWP, и никакие сторонние привязки не считаются, не все наделены юридическим отделом, который разрешает что угодно, без учета лицензий и будущих проблем поддержки.

Borland (теперь Embarcadero) и The Qt Company показали, как это сделать, и Microsoft должна решить, насколько актуальной они хотят сохранить платформу.

Попробуйте увидеть, как далеко вы продвинетесь с ISO C ++ в графических интерфейсах macOS, iOS, Android, ChromeOS.

Во всяком случае, останавливаться здесь бессмысленно.

@pjmlp у нас есть кроссплатформенные приложения с миллионами строк ISO C ++, которые отлично работают на iOS / macOS / Windows. C ++ - единственный язык, который можно использовать, когда вы заботитесь о производительности и / или времени автономной работы. Расширения C ++ нам не подходят, поскольку мы используем несколько компиляторов (которые, очевидно, не реализуют расширения друг друга).
Раньше мы использовали C ++ / CLI, и это такая боль. Ограничения, такие как члены класса, допускающие только необработанные указатели C ++, затрудняют хранение интеллектуальных указателей. Время компиляции велико (для изменения одного символа требуется 5 минут MD Merge).
C ++ включает требование обертывания для изменения управляемой / неуправляемой прагмы
Компилятор - это другая версия для C ++ / CLI по сравнению с C ++ (и мне сказали при сборке, что компилятор C ++ / CLI не будет поддерживать позже, чем C ++ 17, что является проблемой при включении заголовков из библиотек, использующих C ++. 20 функций).
Я пытаюсь сказать, что не предпринимайте нескольких конкурирующих усилий. Придерживайтесь стандарта и работайте с ним. Microsoft входит в комитет C ++, они помогают продвигать стандарт, это должно быть в центре внимания, а не проприетарным, закрепленным за расширениями.

Можно ли иметь компилятор xaml, например xaml.exe, для компиляции файлов xaml, аналогичный midl.exe, cl.exe или link.exe? Было бы очень полезно построить автоматический конвейер для приложения winui.

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

Это требуется для таких сценариев, как cmake: https://github.com/microsoft/ProjectReunion/issues/58

Можно ли иметь компилятор xaml, например xaml.exe, для компиляции файлов xaml, аналогичный midl.exe, cl.exe или link.exe? Было бы очень полезно построить автоматический конвейер для приложения winui.

@sammi # 1433 обобщает правдоподобное решение того, что вы ищете?

Можно ли иметь компилятор xaml, например xaml.exe, для компиляции файлов xaml, аналогичный midl.exe, cl.exe или link.exe? Было бы очень полезно построить автоматический конвейер для приложения winui.

@sammi # 1433 обобщает правдоподобное решение того, что вы ищете?

@jtbrower , это именно та функция, которую я ищу, спасибо!

Конечно, это предварительный просмотр, и это означает, что я не должен ожидать многого, но предварительный просмотр WinUI 3 Preview 2 меня разочаровал.

Моя самая большая потребность связана с проектированием XAML. Я был очень ошеломлен тем фактом, что конструктор XAML вообще не работал, и пока я не нашел четкой информации о том, когда он заработает.

Да, я согласен, что текущий конструктор XAML в Visual Studio очень медленный, и он ломается, когда кто-то меняет что-то в реальном времени, что на самом деле не должно его ломать. Например, изменение Height="*" на "Auto" или 100. (окно ошибки выдает около 10 ошибок - изобилие волнистых линий, и вам нужно перестроить проект)

Для ясности - я на самом деле не использую конструктор для проектирования - я просто хочу иметь представление о том, выглядит ли мой макет так, как я его представлял до прохождения процесса сборки. Если бы проще, если бы дизайнер был просто «Только просмотр» и он обновлялся по мере того, как я настраивал XAML (без сбоев), это было бы для меня нормально, поскольку я не использую графический интерфейс для изменения XAML .. или очень редко . Действительно, то, что WindowsCommunityToolkit делает с исходным кодом XAML, который позволяет пользователю изменять источник и видеть результат в реальном времени, достаточно для моих целей.

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

Я надеюсь, что Project Reunion также полностью отделит графический интерфейс от контейнера приложения. UWP-подобный UX без песочницы / границ был бы большим шагом вперед.

Но когда у нас может быть конструктор XAML, который снова будет работать ... пожалуйста?

Я думаю, что горячая перезагрузка по большей части устарела, если конструктор XAML предназначен только для просмотра.

Но здесь мы говорим об инструментах WinUI. Горячая перезагрузка и живое визуальное дерево также не работают для WinUI.

Под дизайнером только для просмотра я имел в виду: «Я мог бы согласиться на это, если бы это было что-то, что мы могли бы включить в предстоящий предварительный просмотр».

Я могу ошибаться (И, пожалуйста, СКАЖИТЕ меня, если я ошибаюсь), но прямо сейчас единственный способ увидеть ваш пользовательский интерфейс в WinUI - это создать и запустить его.

Но здесь мы говорим об инструментах WinUI. Горячая перезагрузка и живое визуальное дерево также не работают для WinUI.

Под дизайнером только для просмотра я имел в виду: «Я мог бы согласиться на это, если бы это было что-то, что мы могли бы включить в предстоящий предварительный просмотр».

Я могу ошибаться (И, пожалуйста, СКАЖИТЕ меня, если я ошибаюсь), но прямо сейчас единственный способ увидеть ваш пользовательский интерфейс в WinUI - это создать и запустить его.

Привет, @ ericleigh007, у тебя была возможность ознакомиться с нашей последней версией WinUI 3 Preview 3? Недавно мы добавили множество улучшений инструментов, таких как IntelliSense, Hot Reload, Live Visual Tree и Live Property Explorer. Вы можете проверить примечания к выпуску здесь и получить последнюю предварительную версию здесь . Мне интересны ваши мысли, поэтому, пожалуйста, свяжитесь с нами!

@JeanRoca К сожалению, освоение опыта разработки C ++ / CX не было одним из тех улучшений инструментария. Не ожидайте большой любви разработчиков к WinUI, когда предлагаемый инструментарий C ++ кажется возвращением в 2000 год, записывает файлы IDL в блокнот (без поддержки какого-либо редактора) и вручную копирует файлы.

Это заставляет меня оставаться в .NET как можно дольше или просто продолжать использовать C ++ / CX, несмотря на предупреждения о переходе на C ++ / WinRT.

Спасибо за обновления; Попробую сегодня и доложу. 🤞

Отправлено из почты https://go.microsoft.com/fwlink/?LinkId=550986 для Windows 10

От: JeanRoca [email protected]
Отправлено: среда, 18 ноября 2020 г., 4:41 утра
Кому: microsoft / microsoft-ui-xaml [email protected]
Копия: Эрик [email protected] ; Упомяните упоминание@noreply.github.com
Тема: Re: [microsoft / microsoft-ui-xaml] Опыт и инструменты разработчика WinUI 3.0 - требуются вводные данные (№ 1045)

Но здесь мы говорим об инструментах WinUI. Горячая перезагрузка и живое визуальное дерево также не работают для WinUI.

Под дизайнером только для просмотра я имел в виду: «Я мог бы согласиться на это, если бы это было что-то, что мы могли бы включить в предстоящий предварительный просмотр».

Я могу ошибаться (И, пожалуйста, СКАЖИТЕ меня, если я ошибаюсь), но прямо сейчас единственный способ увидеть ваш пользовательский интерфейс в WinUI - это создать и запустить его.

Эй @ ericleigh007 https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericleigh007&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637412713160082691%7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = jha7IQJyg% 2BKEZLEgBiKvA зарезервировано 2BKEZLEgBiKvA Недавно мы добавили множество улучшений инструментов, таких как IntelliSense, Hot Reload, Live Visual Tree и Live Property Explorer. Вы можете проверить примечания к выпуску здесь https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F3620&data=04%7C01% 7С% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160082691% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & SData = 2jVKkAs9Whd6U9kH1ZxJKy956wI6Itg7jq6lCuaqEgE% 3D & зарезервирован = 0 и получить последнюю превью здесь https://eur05.safelinks.protection.outlook.com/?url=https% 3A% 2F% 2Fdocs.microsoft.com% 2Fen-связь% 2Fwindows% 2Fapps% 2Fwinui% 2Fwinui3% 2F & данные = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & SData = VF2s7jilqpksevP6Fx7mXW1QCNJN2% 2BK5yWOndg3rKoc% 3D & reserved = 0 . Мне интересны ваши мысли, поэтому, пожалуйста, свяжитесь с нами!

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F1045%23issuecomment -729402012 & данные = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & SData = R1S2JpfBSzsNKJBAH5% 2Fgme8Bq% 2FjHbzB9FySk1KnZKbk% 3D & зарезервирован = 0 , или отменить подписку HTTPS: //eur05.safelinks.protection.outlook .com /? URL = HTTPS% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-AUTH% 2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ & данные = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160102680% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & SData = 0H6IpND3YX1s6oyXy% 2FCXNAMN9n8fvSPdWks% 2FfmXT0Bc% 3D & reserved = 0 .

-Нет сейчас нет редактора / метода wysiwyg, который работал бы с winui3 c ++ (рабочий стол), верно?

Microsoft также удается оттолкнуть пользователей C ++ / CX? Все это складывается не очень хорошо. Любой, кто принял технологию, которую Microsoft продвигала несколько лет назад для UWP, будь то .net или c ++, сейчас испытывает проблемы без поддержки со стороны Microsoft.

Кажется, WinUI 3 обслуживает только настольные приложения, написанные на WPF, но они быстро поймут, что UWP не обладает всеми функциями WPF и WinUI без функций. Все будут разочарованы, а это плохое место для запуска WinUI 3.

@robloo Как кто-то, кто раньше защищал UWP, они потеряли меня, это WPF и Win32, пока они не разберутся с беспорядком.

C ++ / WinRT был политическим ходом, и нам сказали просто принять его и подождать, пока ISO C ++ в конечном итоге обеспечит поддержку рефлексии и метаклассов, чтобы команда Visual Studio могла воспроизвести опыт C ++ / CX.

Как уже упоминалось, даже редактирование файлов IDL ничем не отличается от использования необработанного Блокнота.

То, что нам в .NET пришлось мириться с тем, что Microsoft не предоставила нам все компоненты UWP, было каким-то образом смириться с C ++ / CX, предлагающим опыт, подобный C ++ / CLI. Теперь с C ++ / WinRT мы вернулись к ATL.

Затем, прочитав обсуждения проблем Реюньона и план обновления, становится ясно, что на корректировку курса уйдет несколько лет.

WPF и Win32 могут быть старыми, но они здесь и работают, без повторной перезаписи и потери функций.

-Нет сейчас нет редактора / метода wysiwyg, который работал бы с winui3 c ++ (рабочий стол), верно?

Конструктор XAML вроде как работает, но он изначально не был предназначен для редактирования wysiwyg. Горячая перезагрузка (которая теперь работает в превью 3) работает лучше.

живое визуальное дерево и живой вид опоры отлично работают в предварительном просмотре 3. Когда планируется появление дизайнера?

Также заметил, что дизайнер рабочего стола (WPF) (не UWP) раньше работал в 2.4 (или что-то в этом роде), но теперь мои тесты не видят, что он снова работает? Мне что-то не хватает в текущем состоянии дизайнера?

Извини, что опоздал на вечеринку. @wjk добился этого своим первым очком.

1. С MSIX все хорошо, но я все еще использую старый добрый MSI для установки более сложных приложений, требующих функций, которые MSIX не поддерживает. Я также с подозрением отношусь к использованию MSIX из-за того, насколько дороги требуемые сертификаты Authenticode.

Я действительно ценю очарование MSIX, но этот мандат на подписание сертификатов является для меня нарушением условий сделки. Мне нужен подходящий мастер установки с поддержкой SCM, который я могу использовать для создания классического установщика рабочего стола. Почему бы не воспользоваться улучшениями в MSIX и не создать новую версию установщика MSI без Microsoft Store и требований сертификации для более современного опыта разработки? Возможно, это то, что имеется в виду под функцией «Поддерживает развертывание без MSIX», перечисленной в текущей дорожной карте ? Если так, то я застрял в ожидании 3.x, если только каким-то чудом он не попадет в более раннюю версию. С нетерпением жду этого, потому что проекты VS Installer трагически устарели и совсем не подходят для управления версиями. 😓

@Chiramisu Я согласен с мнением, но я также сбит с толку - как насчет опыта загрузки неопубликованных приложений + недостаточно AppInstaller?

@Chiramisu Вы пробовали WiX ? Я использую его для всех своих установщиков на основе MSI, и он работает очень и очень хорошо. Также есть расширение Visual Studio , поэтому у вас могут быть проекты WiX, которые автоматизируют различные команды компиляции.

@robloo Как кто-то, кто раньше защищал UWP, они потеряли меня, это WPF и Win32, пока они не разберутся с беспорядком.

C ++ / WinRT был политическим ходом, и нам сказали просто принять его и подождать, пока ISO C ++ в конечном итоге обеспечит поддержку рефлексии и метаклассов, чтобы команда Visual Studio могла воспроизвести опыт C ++ / CX.

Как уже упоминалось, даже редактирование файлов IDL ничем не отличается от использования необработанного Блокнота.

То, что нам в .NET пришлось мириться с тем, что Microsoft не предоставила нам все компоненты UWP, было каким-то образом смириться с C ++ / CX, предлагающим опыт, подобный C ++ / CLI. Теперь с C ++ / WinRT мы вернулись к ATL.

Затем, прочитав обсуждения проблем Реюньона и план обновления, становится ясно, что на корректировку курса уйдет несколько лет.

WPF и Win32 могут быть старыми, но они здесь и работают, без повторной перезаписи и потери функций.

Просто чтобы я не отставал, не могли бы вы подсказать мне, о каком редактировании IDL вы говорите с помощью C ++ / WinRT? Судя по тому, что я видел для co_await и другого синтаксиса C ++ 17, сложность, похоже, значительно возросла по сравнению с C ++ / CX.

РС? Разве не возможно, что, если кто-то не создаст вокруг этого действительно хороших оболочек, C ++ / WinRT, основанный на возможностях C ++ 17, будет слишком сложным и слишком отличным от текущих проектов? Разве нельзя было сохранить C ++ / CX в достаточном количестве, чтобы создать некую «отличную оболочку» для C ++ 17, чтобы сделать C ++ / WinRT достаточно простым в использовании и переходе на него?

(теперь кто-то собирается дать ссылку на статью, в которой показано, как это делается, и я буду чувствовать себя глупо)

@lmcdougald Я еще не пробовал. Следует отметить, что мой конкретный проект все еще находится на .NET Framework 3.5. Я знаю я знаю. Мне еще не разрешили обновлять его, поэтому я застрял в том, какая технология установщика будет работать с этим древним фреймворком. 😖

@wjk Я изучал это в прошлом, но нет, я еще не пробовал. Хотя, учитывая вышесказанное, похоже, что это единственная технология, которая может работать для моего существующего проекта, как есть. Вы случайно не использовали это для приложений WinForms, основанных на старой структуре? К сожалению, я разработчик-одиночка, поэтому мне приходится проявлять крайние предубеждения в отношении того, как я провожу свое время, и не имею права экспериментировать с новыми технологиями.

Любезно

@Chiramisu Да, WiX работает со старыми версиями .NET Framework, и да, он также работает с приложениями winforms. Поскольку он создает необработанные файлы MSI, WiX может установить что угодно на любом языке программирования. Что касается его изучения, я бы начал с базовых руководств . Я также хотел бы указать, как определить, установлен ли .NET , и как запустить NGEN для файлов с помощью WiX , поскольку вы используете эти технологии в своем приложении. Расширение Visual Studio также поставляется с рядом шаблонов проектов, чтобы дать вам правильный скелетный код для добавления. (Примечание: не используйте шаблон Bootstrapper, поскольку это более сложная тема.) Надеюсь, это поможет!

@Chiramisu Меня так смущает то, что вы ищете - мне кажется, что вы ищете инструменты упаковки для своего текущего проекта, а не для проекта WinUI 3.0.

Стоит отметить, что .NET Framework 3.5 можно упаковать в MSIX. Вы можете создать пакет MSIX для своего существующего приложения с помощью Package Project в VS 2019, а затем без проблем пройти долгий переход, но это большая работа:

WinUI 3.0 никогда официально не будет поддерживать .NET 3.5 и, вероятно, никогда не будет поддерживать .NET Framework ни ​​в одной версии. Я бы начал вашу модернизацию с стремления перейти на .NET 4.6 (или, в идеале, выше, 4.8 было бы идеально) без изменения существующего проекта упаковки. Если все пойдет гладко, я бы начал переносить функциональные возможности в общую библиотеку .NET Standard, на которую вы ссылаетесь из своего обновленного приложения .NET 4.6+.

После того, как приложение .NET 4.6 станет стабильным и протестированным, вы можете заменить его как автоматическое обновление для вашего проекта упаковки MSIX. После этапа .NET Standard вы можете создать заголовок проекта, который использует почти тот же код из .NET Core 3.1 (или 5, но мне кажется, что статус LTS, вероятно, что-то значит для вашей организации). Опять же, протестируйте, а затем переключите MSIX на использование этой версии.

Переход на WinUI с WinForms на этом этапе - это вопрос изучения WinUI и повторной реализации интерфейса. Снова создайте новый заголовок проекта, внедрите + сделайте ссылку на библиотеку .NET Standard, протестируйте, а затем переключите пакет на использование этой версии.

Вот как я бы пошел на модернизацию, не создавая резко расходящихся проектов в любой момент. Я бы предпочел установить пакет MSIX и шаги .NET 4.6 + .NET Standard, так как они принесут вам огромное количество дополнительных инструментов помощи и подключение к современному циклу разработки .NET. Спешный переход на .NET 5 звучит как плохая идея для вашей организации в краткосрочной перспективе, учитывая, что ее жизненный цикл составляет 1/10 от срока существования .NET 3.5.

Просто чтобы я не отставал, не могли бы вы подсказать мне, о каком редактировании IDL вы говорите с помощью C ++ / WinRT? Судя по тому, что я видел для co_await и другого синтаксиса C ++ 17, сложность, похоже, значительно возросла по сравнению с C ++ / CX.

РС? Разве не возможно, что, если кто-то не создаст вокруг этого действительно хороших оболочек, C ++ / WinRT, основанный на возможностях C ++ 17, будет слишком сложным и слишком отличным от текущих проектов? Разве нельзя было сохранить C ++ / CX в достаточном количестве, чтобы создать некую «отличную оболочку» для C ++ 17, чтобы сделать C ++ / WinRT достаточно простым в использовании и переходе на него?

(теперь кто-то собирается дать ссылку на статью, в которой показано, как это делается, и я буду чувствовать себя глупо)

Поскольку обычный C ++ не имеет возможности извлекать метаданные типа, необходимые для создания файла .winmd, вам необходимо записать классы WinRT в файле .idl поверх .hpp и .cpp.

co_await намного проще, чем писать везде .then([=](Foo^ thing) { }) , он очень похож на синтаксис await в C #.

Вот пример (idl + hpp + cpp) из проекта компонента времени выполнения по умолчанию:

namespace RuntimeComponent6
{
    runtimeclass Class
    {
        Class();
        Int32 MyProperty;
    }
}

#pragma once

#include "Class.g.h"

namespace winrt::RuntimeComponent6::implementation
{
    struct Class : ClassT<Class>
    {
        Class() = default;

        int32_t MyProperty();
        void MyProperty(int32_t value);
    };
}

namespace winrt::RuntimeComponent6::factory_implementation
{
    struct Class : ClassT<Class, implementation::Class>
    {
    };
}

#include "pch.h"
#include "Class.h"
#include "Class.g.cpp"

namespace winrt::RuntimeComponent6::implementation
{
    int32_t Class::MyProperty()
    {
        throw hresult_not_implemented();
    }

    void Class::MyProperty(int32_t /* value */)
    {
        throw hresult_not_implemented();
    }
}

Вот небольшой пример co_await:

void PrintFeed(SyndicationFeed const& syndicationFeed)
{
    for (SyndicationItem const& syndicationItem : syndicationFeed.Items())
    {
        std::wcout << syndicationItem.Title().Text().c_str() << std::endl;
    }
}

IAsyncAction ProcessFeedAsync()
{
    Uri rssFeedUri{ L"https://blogs.windows.com/feed" };
    SyndicationClient syndicationClient;
    SyndicationFeed syndicationFeed = co_await syndicationClient.RetrieveFeedAsync(rssFeedUri);
    PrintFeed(syndicationFeed);
}

Всем привет,

Мы читаем ваши отзывы и делаем заметки о болевых точках.

@ ericleigh007 Конструктор XAML был отключен, потому что после сбора отзывов клиентов дорожной карте . Согласно текущему инженерному плану, он вышел из RTM версии 3.0, так что это версия после версии 3.0.

@pjmlp Я сочувствую вашей раскраске о C ++ / WinRT и необходимости добавления IDL. В этом отношении C ++ / CX намного лучше. Еще одна тема, которую нам нужно решить, - это улучшение взаимодействия с C ++ / WinRT. Такие инструменты, как Live Visual Tree и Hot Reload, работают как на C #, так и на C ++, но есть определенные вещи, которые влияют только на C ++ и требуют отдельного решения. Согласно текущему инженерному плану, решение проблемы IDL не входит в RTM версии 3.0.

@robloo , мы не обслуживаем десктопные приложения, написанные на WPF. C ++ / WinRT - первый гражданин экосистемы WinUI. Это то, что мы используем для написания WinUI, поэтому мы стараемся использовать наши надлежащие инструменты и языки.

@Chiramisu Позвольте мне объяснить, что означает «поддерживает развертывание без MSIX». Сегодня вам нужно установить и запустить приложение WinUI 3 для настольных ПК с помощью MSIX. Эта возможность устраняет эту потребность. Чтобы запустить приложение WinUI 3 для рабочего стола, вам нужно всего лишь удвоить файл .EXE, и все. Чтобы установить приложение, вы можете просто сделать xcopy (не нужно ничего подписывать). По сути, вы сможете использовать другие системы упаковки и установки, такие как WiX.

@ marb2000 Спасибо за подтверждение проблемы. Чего я и многие другие разработчики Windows не понимаем, так это то, почему вы (как и в руководстве WinDev) решили, что было бы неплохо применить грубую силу C ++ / WinRT к нам с помощью более слабых инструментов, даже возвращаясь к MFC, кажется лучше, по крайней мере, мы не Не копирую файлы вручную.

Прямо сейчас я сосредотачиваюсь на ASP.NET, WFP и Win32, просто продолжайте следить за материалами UWP в надежде, что Microsoft в конце концов поймет, что нам надоело переписывать приложения и перетаскивать ручные настройки, как в UAP => UWP переход, .NET Framework на .NET Core, или да C ++ / CX => C ++ / WinRT.

Это больше похоже на обратную связь, так как я являюсь активным участником сообщества разработчиков Windows, которое чувствует себя немного разочарованным из-за постоянных переписываний с момента появления Windows 8.

@pjmlp Я не уверен, почему вы критикуете C ++ / WinRT, который является просто (стандартной) оболочкой C ++ для Windows API. Можно писать приложения на C ++ / WinRT без использования инструментов (и файлов IDL и т. Д.).

@pjmlp Я не уверен, почему вы критикуете C ++ / WinRT, который является просто (стандартной) оболочкой C ++ для Windows API. Можно писать приложения на C ++ / WinRT без использования инструментов (и файлов IDL и т. Д.).

В этом и состоит проблема: нулевая поддержка инструментов по сравнению с опытом разработки C ++ / CX в Visual Studio.

Никакой поддержки редактирования для файлов IDL, даже подсветки синтаксиса, не говоря уже о intelisense. И затем вам предлагается вручную скопировать или объединить сгенерированные единицы перевода!

Это как когда-то заниматься ATL.

Меня не волнует совместимость ISO C ++, в любом случае UWP - это только Windows, и нет компиляторов C ++ без языковых расширений.

Я не понимаю, как кто-то может видеть в этом прогресс, кроме ребят из WinDev, которые были единственными пользователями WRL.

@pjmlp ,

Меня не волнует совместимость ISO C ++, в любом случае UWP - это только Windows, и нет компиляторов C ++ без языковых расширений.

Для тех из нас, кто пишет большие кроссплатформенные приложения на C ++, соблюдение стандартов имеет большое значение. Ограничения C ++ / CX были ужасными (нет переменных-членов, которые не являются необработанными указателями, шляпами! ( ^ ) и т. Д.). В настоящее время у нас есть большая библиотека взаимодействия C ++ / CLI, и болевые точки слишком многочисленны, чтобы их перечислить.

Никакой поддержки редактирования для файлов IDL, даже подсветки синтаксиса, не говоря уже о intelisense. И затем вам предлагается вручную скопировать или объединить сгенерированные единицы перевода!

Опять же, вы объединяете C ++ / WinRT и инструменты. Это две разные вещи. C ++ / WinRT - это оболочка C ++ для API WinRT. IDL предназначен для генерации кода, и да, я согласен, это ужасно, настолько плохо, что я его не использую.

Я пишу приложение только для Windows, и меня по-прежнему волнует соответствие стандартам, поскольку оно позволяет мне использовать другой компилятор в случаях, когда MSVC не работает.

@MarkIngramUK

Опять же, вы объединяете C ++ / WinRT и инструменты. Это две разные вещи. C ++ / WinRT - это оболочка C ++ для API WinRT. IDL предназначен для генерации кода, и да, я согласен, это ужасно, настолько плохо, что я его не использую.

Я программировал для платформ Microsoft с MS-DOS 3.3, добавил C ++ в свой набор инструментов в 1992 году с Turbo C ++ 1.0, использовал большинство продуктов Borland и Microsoft в том, что касается разработки на C ++. Не нужны лекции о C ++ / WinRT.

Чего это определенно не так, так это совпадение с опытом разработчиков C ++ Builder и Qt (с Qt Designer), который обещал, что C ++ / CX в конечном итоге сможет его догнать 25 лет спустя.

Но, по-видимому, большинство людей здесь просто хотят Visual C ++ 6.0 с ATL 3.0, а остальным из нас следует просто придерживаться .NET 5, WPF и Win32 для настольных ПК, потому что мы меньшинство, не заслуживающее внимания, иначе C ++ / WinRT никогда бы не получил толкнули так, как это было.

Давайте будем честными, C ++ / WinRT сейчас почти 4 года, а Microsoft даже не смогла предоставить поддержку даже для подсветки синтаксиса и Intelisense?

То, что некоторые из нас создали в Notepad ++ (подсветка синтаксиса), правда?

Это определенно показывает, где находятся приоритеты, и это не значит, что WinUI получит распространение, слишком много переписываний со времен Windows 8.

@pjmlp , ты опять говоришь не о том. C ++ / WinRT - это просто C ++, поэтому он имеет подсветку синтаксиса и поддержку intellisense. Точно так же, как любой другой код на C ++, который у вас есть.

Интеграция IDE могла бы быть лучше, например, как вы упомянули, выделение синтаксиса IDL и тому подобное, например, предложение создать реализацию по умолчанию в .hpp и .cpp из IDL (например, как в настоящее время функция, объявленная без определения в заголовке, предлагает вам зеленые волнистые линии, чтобы создайте его), но возвращение к C ++ / CX - это чистое понижение версии IMO. Потребовалось бы слишком много усилий, чтобы интегрировать все библиотеки и общий код, которые я использую с C ++ / CX, и вынудить меня понизить рейтинг моего проекта с C ++ 20 до C ++ 17 (от чего я не хочу отказываться, 20 дает мне слишком много хорошего).

C ++ / WinRT также гораздо менее навязчив, чем C ++ / CX, когда программы просто хотят использовать классы WinRT, а не создавать их.

Qt и C ++ Builder достигли своего опыта в основном совместимом со стандартами C ++ (обратите внимание, что Qt имеет нечто похожее на IDL, названное Qt MOC). Если они могут, то и VS. Просто требуется больше любви от кого-то из DevDiv.

И как вы упомянули ранее @sylveon , мы можем создавать с другими компиляторами (в настоящее время мы собираем с помощью MSVC и Clang / LLVM). С C ++ / CX или другими расширениями MS это было бы невозможно.

@MarkIngramUK и @sylveon

Я закончил с этой веткой, совершенно ясно, что обратная связь, подобная моей, не приветствуется для улучшения опыта разработки и инструментов WinUI.

Получайте удовольствие от своего стандартного C ++ / WinRT.

Можете ли вы отредактировать это, чтобы исправить опечатку "без кейтеринга" .. Я думаю, это должно быть "сейчас ..."

@pjmlp Думаю, я ТОЧНО понимаю, что вы имеете в виду.

Примерно год назад я отказался от идеи переноса моего кода UWP C ++ / CX на C ++ / WinRT. Стимулом к ​​переносу была возможность использовать Clang для компиляции моего приложения UWP, потому что MSVC ++ содержит ошибку, о которой я сообщил около 18 месяцев назад, но они, похоже, просто не заинтересованы в исправлении.

Однако затем выяснилось, что Visual Studio не поддерживает создание приложений UWP с использованием Clang. Отлично, поэтому преимущество C ++ / WinRT «только ISO C ++» исчезло. Добавьте к этому тот факт, что перенос базы кода C ++ / CX поверх C ++ / WinRT - это как путешествие на 20 лет назад.

По сути, я отказался от переноса наших приложений для Android / iOS на Windows. Для такого небольшого магазина, как мы, просто невозможно иметь дело с кластерными проблемами, которые связаны с разработкой приложений для Windows в дополнение к разработке для Android / iOS.

@MarkIngramUK Похоже, вы просто не понимаете, что инструменты ОЧЕНЬ ВАЖНЫ. Не у всех есть ресурсы, чтобы компенсировать отсутствие надлежащего инструментария.

Теперь, после моей тирады, вот мой вклад:

Поддержка использования WinUI 3 с C ++ / CX. Как только инструментарий для C ++ / WinRT станет приемлемым для компаний, у которых нет ресурсов для создания собственных инструментов, можно будет перейти на C ++ / WinRT. Теперь это точно не так.

@pjmlp Думаю, я ТОЧНО понимаю, что вы имеете в виду.

Примерно год назад я отказался от идеи переноса моего кода UWP C ++ / CX на C ++ / WinRT. Стимулом к ​​переносу была возможность использовать Clang для компиляции моего приложения UWP, потому что MSVC ++ содержит ошибку, о которой я сообщил около 18 месяцев назад, но они, похоже, просто не заинтересованы в исправлении.

Однако затем выяснилось, что Visual Studio не поддерживает создание приложений UWP с использованием Clang. Отлично, так что преимущества C ++ / WinRT «только ISO C ++» исчезли. Добавьте к этому тот факт, что перенос базы кода C ++ / CX поверх C ++ / WinRT - это как путешествие на 20 лет назад.

По сути, я отказался от переноса наших приложений для Android / iOS на Windows. Для такого небольшого магазина, как мы, просто невозможно иметь дело с кластерными проблемами, которые связаны с разработкой приложений для Windows в дополнение к разработке для Android / iOS.

@MarkIngramUK Похоже, вы просто не понимаете, что инструменты ОЧЕНЬ ВАЖНЫ. Не у всех есть ресурсы, чтобы компенсировать отсутствие надлежащего инструментария.

Теперь, после моей тирады, вот мой вклад:

Поддержка использования WinUI 3 с C ++ / CX. Как только инструментарий для C ++ / WinRT станет приемлемым для компаний, у которых нет ресурсов для создания собственных инструментов, можно будет перейти на C ++ / WinRT. Теперь это точно не так.

Из любопытства, о какой ошибке сообщили 18 месяцев назад? У вас есть где-нибудь на него ссылка?

привет Мигель,
___ отредактировано, чтобы исправить ужасное положение вещей после ответа из Outlook для Android___

У меня возникла идея, которая может прояснить ваши цели для предварительных версий и выпусков, поскольку вы сказали, что платформа Winrt - это то, что вы используете для разработки WINUI.

возьмите эту статью, в которой говорится о том, что IDL пишет и вручную копирует файлы if, и модифицируйте ее, чтобы она соответствовала состоянию, над которым вы работаете в инструментах

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property

Если не здесь, возможно, мы сможем обсудить это где-нибудь еще.

Кстати, вы убедили меня в дизайнере XAML, особенно с инструментами, которые существуют, такими как студия XAML. (если бы он только мог загрузить некоторый код позади, чтобы он мог успешно загрузить XAML, который использует IValueConverter ...

Как упоминалось в моем предыдущем посте, стандартное соответствие C ++ 17 C ++ / WinRT само по себе в большинстве случаев не является стимулом для миграции базы кода C ++ / CX на C ++ / WinRT, потому что вы вынуждены компилировать с помощью компилятора Microsoft Visual C ++. в любом случае. Если бы вы могли отключить компилятор, это бы полностью изменилось.

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

Мы используем Clang для компиляции нашей базы кода для Android и iOS. Возможность использовать Clang для компиляции нашей базы кода для Windows на самом деле была бы очень хорошей причиной для перехода от C ++ / CX. Запрос функции Visual Studio для этого уже существует, но команда Visual Studio пока ничего не сделала.

У вас есть стандартное соответствие C ++, у вас есть поддержка Clang в Visual Studio для настольных приложений. Итак, сделайте последний шаг и укажите реальную причину перехода с C ++ / CX, предоставив поддержку Clang для компонентов среды выполнения Windows.

Соответствие стандартам полезно для потребителей - как вы упомянули, производители придерживаются MSVC. Есть способ "принудительно" clang-cl (это фактически то, что уже делает набор инструментов LLVM ), установив для свойства CLToolExe путь к clang-cl в файле .vcxproj . Я не уверен, насколько хорошо это работает в проектах UWP, но попробовать стоит.

Как только инструменты производителя XAML и C ++ / WinRT будут разблокированы в настольных проектах, это также станет для меня меньшей проблемой.

@ackh У меня есть проект UWP для сборки под Clang 11:

Вот что я сделал:

• Выгрузите проект и добавьте следующую директиву в качестве первой директивы в <Project>

  <PropertyGroup>
    <CLToolExe>C:\Program Files\LLVM\bin\clang-cl.exe</CLToolExe>
  </PropertyGroup>

• Замените <AdditionalOptions>%(AdditionalOptions) /bigobj</AdditionalOptions> на <AdditionalOptions>%(AdditionalOptions) /bigobj -Xclang -std=c++20 -mcx16</AdditionalOptions>
• Замените <PreprocessorDefinitions>WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions> на <PreprocessorDefinitions>_SILENCE_CLANG_COROUTINE_MESSAGE;WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>
• Прямо под этим добавьте <ModuleOutputFile />
• Перезагрузить проект
• Строить

Однако у него есть пара подводных камней:

• Некоторые предупреждения относительно неиспользуемых аргументов поддерживают: вы, вероятно, могли бы исправить их, изменив / удалив неиспользуемые аргументы.
• По какой-то причине Clang генерирует 64-битный объектный файл в 32-битном формате, может потребоваться просто добавить -m32 в CLI tho.
• Поскольку Clang еще не полностью реализует сопрограммы, вы не сможете их использовать.
• VS выполняет полную однопоточную перестройку каждый раз, когда вы запускаете приложение, а не инкрементно и / или параллельно.

Я предлагаю открыть вопрос на https://github.com/microsoft/ProjectReunion, чтобы привлечь к этому внимание.

@sylveon Большое спасибо за размещение этих инструкций. В какой-то момент я попробую это сделать, но все же надеюсь, что Visual Studio в какой-то момент будет поддерживать это из коробки.