Спасибо, что прислушались к отзывам сообщества. Я очень рад WinUI 3.0 (Win32 + WinUI + C ++). Это похоже на фреймворк, которого мы так долго ждали! RIP GDI 😉

(Модель приложения Win32) + (Пользовательский интерфейс WinUI 3.0) + (язык .NET или C ++)

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

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

Да, и документация о том, как WinUI в Desktop будет работать и отличаться от UWP, WPF и Win32, будет очень полезна, чтобы предупредить возникновение бесчисленного количества вопросов.

Возможно, это хорошая матрица того, что включено в какую комбинацию фреймворков и API, а также диаграммы архитектуры, которые мы получили на Build!

Вы, ребята, невероятные, спасибо за все!
Раздел xplat сделал мой день лучше, особенно то, что Uno находится на радаре.

В центре нашего внимания по-прежнему Windows 10 и 8.1, но мы слышим отзывы о том, что у некоторых из вас все еще есть пользователи и клиенты на Win7, и мы будем оценивать рынок и варианты с течением времени.

Предполагая, что эта имплантация инфраструктуры пользовательского интерфейса разработана с учетом идеи переносимости, по крайней мере, достаточно, чтобы ее ядро ​​пользовательского интерфейса (рендеринг / ввод) могло работать под любой ОС Windows, поддерживающей .NET Core 3+, какие ограничения на Windows 7 будут даже быть? Похоже, что большинство функций, которые люди используют на рабочем столе, будут просто работать, а для специальных / специфичных для платформы функций, которые не работают, возможно, они не будут частью основной системы пользовательского интерфейса и сохранят их в пакетах для конкретных платформ, таких как (Win10, Win8.1, Win7 Nugets и т. Д.).

Кроме того, если бы существовал кроссплатформенный XAML, который имел бы одинаковый внешний вид на всех устройствах (Win32, Android, iOS и WASM), как вы можете делать с HTML (но, к сожалению, не с Xamarin), моя компания перешла бы на него много лет назад.

Также рад, что вы, ребята, считаете это «марафоном (и отличной игрой Bungie)». Чем меньше фрагментация в пространстве XAML, тем лучше для всех, и если вы выберете множество сокращений, вы вернетесь туда, где вы начали;)

документация о том, как WinUI на рабочем столе будет работать и отличаться от UWP, WPF и Win32, будет очень полезна.

Мы работаем над этим и будем делиться другими по мере развития!

Предполагая, что эта имплантация инфраструктуры пользовательского интерфейса разработана с учетом идеи переносимости, по крайней мере, достаточно, чтобы ее ядро ​​пользовательского интерфейса (рендеринг / ввод) могло работать под любой ОС Windows, поддерживающей .NET Core 3+, какие ограничения на Windows 7 будут даже быть?

@ zezba9000 WinUI не использует .NET, и вам не обязательно использовать .NET Core с WinUI: это собственная среда, построенная на API ОС, и она полагается на новые функции в Win8 / Win10, которых не было в Win7 - в некоторых случаях для основных функций, а не только для дополнительных функций более высокого уровня, таких как определенные элементы управления.

документация о том, как WinUI на рабочем столе будет работать и отличаться от UWP, WPF и Win32, будет очень полезна.

Мы работаем над этим и будем делиться другими по мере развития!

Предполагая, что эта имплантация инфраструктуры пользовательского интерфейса разработана с учетом идеи переносимости, по крайней мере, достаточно, чтобы ее ядро ​​пользовательского интерфейса (рендеринг / ввод) могло работать под любой ОС Windows, поддерживающей .NET Core 3+, какие ограничения на Windows 7 будут даже быть?

@ zezba9000 WinUI не использует .NET, и вам не обязательно использовать .NET Core с WinUI: это собственная среда, построенная на API ОС, и она полагается на новые функции в Win8 / Win10, которых не было в Win7 - в некоторых случаях для основных функций, а не только для дополнительных функций более высокого уровня, таких как определенные элементы управления.

Для совместимости с Windows 7 - потребуется, чтобы какая-то третья сторона создала собственное совместимое средство визуализации для XAML, а также какую-то альтернативную прокладку для любых необходимых API уровня ОС.

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

это собственная среда, построенная на API ОС, и она полагается на новые функции в Win8 / Win10, которых не было в Win7 - в некоторых случаях для основных функций

На мой взгляд, то, что составляет «основную функцию», не будет зависеть от специфики ОС, кроме, конечно, рендеринга и ввода. В этих случаях это будут уровни абстракции, которые может расширить кто угодно. На базовом уровне теоретически следует иметь возможность отображать пользовательский интерфейс с помощью настраиваемого программного средства визуализации и при желании выполнять ввод с помощью настраиваемого бэкэнда XInput с виртуальным курсором. Если у вас есть такая модульность, вы можете делать что угодно, и расширение поддержки платформы становится чрезвычайно простым (как это делается в играх). Вы проводите в этой области немного больше времени, и в дальнейшем все требует гораздо меньше усилий. Если бы WPF XAML был разработан таким образом, его можно было бы просто взять и использовать в приложениях UWP. В противном случае технический долг превратится в бесконечную петлю.

Такие вещи, как поддержка значков в трее и т. Д., Могут быть в пакете «Основные функции WinUI Windows (Win7-Win10)». Такие вещи, как push-уведомления, могут быть в пакете «Расширенные возможности WinUI Windows (Win8-Win10)».

Надеюсь, это имеет смысл.

@mdtauk , @ zezba9000 все это теоретически возможно, и у нас в команде много опыта в области абстракции платформ. Как и во всем остальном, все сводится только к стоимости, графику и ожидаемой выгоде 😊

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

Ожидаете ли вы, что в 2020+ у Win7 появятся новые клиенты? Отзывы и конкретные варианты использования помогают нам расставить приоритеты.

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

Ожидаете ли вы, что в 2020+ у Win7 появятся новые клиенты? Отзывы и конкретные варианты использования помогают нам расставить приоритеты.

@jesbis Я не вижу особой выгоды в добавлении совместимости с Win7 для WinUI 3.0 - Linux, Android, iOS, iPadOS и MacOS, однако, могут быть полезны для предоставления кроссплатформенного решения, которое не полагается на собственные фреймворки пользовательского интерфейса.

@mdtauk
@jesbis Я не вижу особой выгоды в добавлении совместимости с Win7 для WinUI 3.0 - Linux, Android, iOS, iPadOS и MacOS, однако, могут быть полезны для предоставления кроссплатформенного решения.

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

Ожидаете ли вы, что в 2020+ у Win7 появятся новые клиенты? Отзывы и конкретные варианты использования помогают нам расставить приоритеты.

Нет, моя компания этого не делает. Я приводил больше аргументов в пользу дизайна в области, в которой я видел, как XAML боролся во всех его итерациях (с моей точки зрения), но я полностью понимаю, почему MS не хочет проводить там время. Однако было бы здорово, если бы WinUI был достаточно способным, чтобы другие могли выполнять эту работу, если бы им было нужно (что, как я заметил, обычно случается), не заходя в кроличью нору зависимостей Windows, как в случае с WPF сейчас.

Чтобы прояснить, что моя компания хотела бы видеть, так это поддержка Android и WASM немного более официальной, чем поддержка UNO (и 3 года назад). Мы создаем программное обеспечение для управления, которое управляет состоянием коллекции локальных компьютеров и системными настройками, обычно связанными с большой потребностью в API Win32 (UWP никогда не будет работать для нас, но нам нравится пользовательский интерфейс из-за ошибок времени компиляции в отличие от систем сборки HTML) и наши клиенты + нам нужны Win32 + Android + интерфейс браузера, которые имеют единообразный интерфейс. HTML - это просто большая проблема, поскольку он добавляет ненужную абстракцию и сложность, которые в противном случае не нужны, поскольку наша основная база кода находится на C #.

Надеюсь, что это лучший отзыв для тебя.

Также да, WASM - это самая большая цель, которую мы хотели бы по сравнению с любой другой платформой. ДАЛЕКО !!
Поскольку он решает нашу проблему с Android / iOS / мобильными устройствами, а также с веб-порталом.

Спасибо, что выслушали отзывы!

Desktop + WASM будет золотым!

Вау, спасибо за привет, @jesbis! Совершенно неожиданно и очень ценится и уважается. 👍

Обсуждение Windows 7 немного отвлекает, поскольку объем усилий (не говоря уже о стоимости) приведет к значительной задержке с WinUI 3.0. Срок службы Windows 7 заканчивается в январе, и мы призываем всех клиентов перейти на Windows 10. Мои клиенты могут не соглашаться с другими здесь, но даже Windows 8.1 не представляет для нас интереса.

Доволен обновлением. Предстоящие задачи для WinUI выглядят очень яркими и многообещающими! Даже раздел Xplat был тем, чего я не ожидал, но это очень приветствуется. Будем с нетерпением ждать возможности использовать улучшения, а также полезности для WinUI.

Спасибо команде за прозрачность.

Хочу отметить важность бизнес-программного обеспечения в помощи людям в решении различных проблем.

Некоторое время я работал с инструментом Lightswitch и значительно выиграл время строительства. Быстрая разработка приложений была очень многообещающей для бизнес-приложений. Но с патентными войнами в США очень серьезно отнеслись, потребовалось, чтобы продукт был прекращен.

Мы знаем, что у нас есть INotifyDataErrorInfo для следующей доставки. Но было бы замечательно, если бы WinUI имел ресурс RAD для будущих поставок, таких как 3.x и новее.

спасибо команде, не могу дождаться того дня, когда вы начнете рисовать в веб-сборке. это сделает мой день, год и десятилетие и поставит MS на вершину технологического стека. WinUI + Xamarin + WASM + .NET => чистое великолепие !!

@jesbis Спасибо за это обновление. Хорошая рабочая команда: +1 :. Понимать, что это еще рано, когда, по вашему мнению, мы увидим создание вехи WinUI 3.0 и проблемы, связанные с ним?

как вы думаете, когда мы увидим создание вехи WinUI 3.0 и проблемы, связанные с ним?

@shaggygi Хороший вопрос! Я только что его создал:

Веха WinUI 3.0

Это классные ребята!

Быстрый вопрос: перенос Windows.UI.Composition в Microsoft.UI.Composition, это ближе к 2.2 или 3.0?
И в сроки, которые можно ожидать, это мне понравится на 2-3 месяца или больше, когда станет доступна версия 3.0?

В будущем, когда вы будете говорить о годах (например, «до конца года»), пожалуйста, можете ли вы четко указать календарные годы и финансовые годы [Microsoft].
Легко запутаться, когда об этом прямо не говорится, и я знал случаи, когда это приводило к тому, что люди полагали, что события произойдут на 6 месяцев раньше, чем предполагалось.

Перемещение Windows.UI.Composition в Microsoft.UI.Composition, это ближе к 2.2 или 3.0?

@jtorjo это будет 3,0 (минимум). Мы надеемся включить раннюю сборку в первую предварительную версию 3.0, но еще не на 100%.

В будущем, когда вы будете говорить о годах (например, «до конца года»), пожалуйста, можете ли вы четко указать календарные годы и финансовые годы [Microsoft].

@mrlacey спасибо, буду иметь это в виду! Все даты, которые мы используем, обычно календарное время.

@jesbis Это грустно. То есть вы говорите, что, возможно, у нас не будет Microsoft.UI.Composition в версии 3.0?

@jtorjo

Мы надеемся включить раннюю сборку в первую предварительную версию 3.0 , но еще не на 100%.

Часто бывает много предварительных выпусков. Например, .NET Core 3 находится в Preview 6.

Мы планируем включить API композиции в 3.0.

Однако часть фреймворка Xaml будет иметь открытый исходный код, а не часть композиции.

@jesbis Спасибо, звучит хорошо!

Фантастическая дорожная карта, отличная работа!

Как и все присутствующие, мне нравится прозрачность, и я действительно с нетерпением жду WinUI 3.0. Для меня WinUI 3.0 - это самая захватывающая вещь с тех пор, как WPF был представлен в 2006 году.

У меня все еще есть клиенты, использующие Windows 7, но я считаю, что поддержка Windows 10 очень важна, и я бы не стал тратить время и ресурсы на поддержку Win7. Большинство компаний, в которых я работаю, переходят на 10. И я думаю, что в конце 2020 года единственная известная мне компания, которая все еще использует Windows 7, вероятно, будет моим дантистом. И если он может попросить меня написать для него приложение для Windows, я перенесу его компьютеры на Windows 10. :-)

Поддержка WASM в будущем будет потрясающей.

Вчера на конференции:

Небольшая история, чтобы показать @jesbis и команду, которую мы пишем и участвуем здесь, - это лишь верхушка айсберга. :-)

Буквально вчера я разговаривал на конференции разработчиков в Германии с некоторыми разработчиками .NET и рассказал им о WinUI 3.0, а они об этом не знали. Я рассказал им о дорожной карте, и они сказали:

«Вау, это потрясающе».

Девушка из группы спросила меня:

«Но можно ли вам все это рассказать?»

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

await Task.Delay(3000);

прежде чем я сказал

«Черт возьми! Вы можете прочитать все это на GitHub».

Спасибо @jesbis и всем участникам. Прекрасное время для разработки Windows ❤️

Я надеюсь, что сторонние приложения (например, Word?) Могут использовать слои WinUI, и разработчики были бы счастливы увидеть, что: «Эй, WinUI - это реальная вещь, которая может управлять бизнесом, а не игрушкой».
Если они уже используют это, скажите это вслух.

Acrylic для WPF, Win32 и WinUI Desktop.

Ну и, возможно, пересмотрите Acrylic only on active windows policy.

Да, если у вас более 1 монитора, он просто отображается в одном окне. По крайней мере, на нескольких мониторах он должен работать правильно ....

Я думал о последствиях для опыта разработки наличия двух наборов элементов управления пользовательского интерфейса, доступных в приложениях UWP - когда у нас будет доступ как к элементам управления WinUI, так и к устаревшим элементам управления пользовательского интерфейса, когда в коде программной части C #, IntelliSense, поскольку он всегда требует от нас правильного выберите пространство имен, из которого должен поступать элемент управления, вместо нажатия Alt + Enter, чтобы просто добавить using и продолжить. Можно ли как-нибудь этого избежать?

После того, как WinUI3 вне для разработчиков, Windows 10 SDKs следует рассмотреть возможность предположить изменение имен для проектов , которые открываются с поддерживаемой SDK установлены. Попытайтесь отвести людей от namspaces ОС.

Acrylic для WPF, Win32 и WinUI Desktop.

В первую очередь я хотел бы увидеть, что MS достаточно созревает Xaml Islands, чтобы, например, акрил в строке заголовка можно было использовать для проектов, не относящихся к UWP, основанных на пользовательском интерфейсе WinUI (см. Последний абзац этого сообщения ). @ marb2000 , вероятно, тот человек, который может спросить об этом.

@MartinZikmund Мы хотим избежать этого сценария. При использовании WinUI 3 у вас должен быть доступ только к элементам управления из пакета. Идея в том, что у нас есть все, что вам нужно, с последними и значительными изменениями.

@MartinZikmund
@LucasHaines

Одно исправление должно заключаться в том, что вы можете исключить ссылки 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, с более быстрыми изменениями, со всеми преимуществами обоих и без каких-либо проблем.

Только что посмотрел потрясающую презентацию Стива Сандерсона о пользовательском интерфейсе Blazor + (не html), заключенном в кроссплатформенное нативное приложение. Примерно через 52 минуты видео. Обязательно к просмотру поклонникам UWP, WinUI и C #. Я серьезно впечатлен блейзером !!!

https://youtu.be/uW-Kk7Qpv5U

Одна вещь, которую я забыл сказать в этих обсуждениях, что считаю важной, это ...
Есть ли улучшения производительности в самом WinUI 3.0? Движок рендеринга XAML просто развязан или в него вносятся изменения? Будут ли элементы управления XAML использовать Composition в основном и, следовательно, вне потока и dwm, как DirectUI?

Некоторые элементы управления производительностью и использованием ОЗУ могут быть намного лучше, например ListView / GridView = ItemsControl.

Вы видите это в самой Windows. Меню Пуск Windows 8 (DirectUI) намного более гибкое, чем меню Пуск XAML Windows 10.
Попробуйте загрузить GridView с достаточным количеством информации, например страницу Groove Albums, и все пойдет не так хорошо. Это то, что iOS и Android ведут себя намного лучше, как и winforms, QT.
(На мой взгляд, WPF даже хуже, чем UWP XAML).

Есть ли улучшения производительности в самом WinUI 3.0? Движок рендеринга XAML просто развязан или в него вносятся изменения? Будут ли элементы управления XAML использовать Composition в основном и, следовательно, вне потока и dwm, как DirectUI?

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

WinUI 3.0 (например, UWP Xaml сегодня) построен на уровне композиции и выполняет большую часть своего рендеринга и анимации вне потока через DWM.

Это то, что iOS и Android ведут себя намного лучше, как и winforms, QT.
(На мой взгляд, WPF даже хуже, чем UWP XAML).

При рассмотрении этих сценариев часто приходится выбирать между производительностью и гибкостью / богатством. Платформы на основе Xaml (включая UWP и WPF), как правило, имеют более крупные и богатые деревья объектов пользовательского интерфейса для каждого элемента управления: это обеспечивает большую гибкость для изменения стиля и пользовательского интерфейса любого элемента управления, в то время как некоторые другие платформы, как правило, имеют гораздо более плоские деревья объектов. которые не так гибки, но иногда могут загружаться быстрее.

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

Я надеюсь, что Microsoft сможет предоставить новые comctl32.dll и comdlg32.dll, основанные на WinUI 3.0.

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

Многим разработчикам Win32 необходимо адаптировать несколько версий Windows. Поэтому сегодня они не могут напрямую использовать WinUI. Было бы здорово, если бы Microsoft могла предоставить метод, который поможет им снизить нагрузку на модернизацию пользовательского интерфейса своих приложений.

Кроме того, я надеюсь, что Microsoft может предоставить конструктор XAML для приложений C ++ Win32, использующих WinUI.

Кенджи Моури

@MouriNaruto, вы можете использовать FileOpenPicker сегодня (из Win32).

@MouriNaruto, вы можете использовать FileOpenPicker сегодня (из Win32).

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

@MouriNaruto

Технически это возможно. Но разработчики Windows должны воссоздать не только точное поведение реализаций COMCTL и COMDLG но также известные и неизвестные ошибки, существующие в кодовой базе.

Совместимость - наш заклятый враг !

Даже если они это сделают, к тому времени, когда они его завершат, у каждого программного обеспечения, использующего эти библиотеки, будет достаточно времени для перехода на WinUI! Ирония!! 🤨🤣

@MarkIngramUK

К вашему сведению : FileOpenPicker не является родным диалогом / элементом управления WinRT. По сути, это оболочка ExplorerFrame которая сама написана в DirectUI (разработана ATG Team и основана на DirectX ) и COM !

Технически это возможно. Но разработчики Windows должны воссоздать не только точное поведение реализаций COMCTL и COMDLG, но также известные и неизвестные ошибки, существующие в кодовой базе.
Совместимость - наш заклятый враг!
Даже если они это сделают, к тому времени, когда они его завершат, у каждого программного обеспечения, использующего эти библиотеки, будет достаточно времени для перехода на WinUI! Ирония!! 🤨🤣

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

Вы сказали: «Совместимость - наш заклятый враг!». Да, это тоже одна из причин моих предложений. Ирония!! 🤨🤣

Я был бы счастлив получить XAML-версию общих диалоговых окон WinUI, даже если WPF и WinForms должны будут согласиться на использование новых версий.

Цель WinUI 3 звучит очень захватывающе, и я с нетерпением жду ее. У меня есть несколько вопросов относительно распространения / развертывания в контексте классического приложения Win32 с использованием WinUI 3.

1. Должно ли каждое приложение иметь с собой свою библиотеку WinUI, или же может делиться между приложениями, возможно, даже автоматически через механизмы Windows?
2. Можно ли будет статически привязать WinUI?
3. Скажем, мне нужно перераспределить его, каков размер WinUI примерно в МБ?

Должно ли каждое приложение иметь с собой свою библиотеку WinUI, или же может делиться между приложениями, возможно, даже автоматически через механизмы Windows?

Мы планируем в первую очередь распространять WinUI 3 через NuGet, который имеет механизмы для автоматического кеширования и обмена пакетами - дополнительная информация доступна здесь:

https://docs.microsoft.com/nuget/what-is-nuget#what -else-does-nuget-do

https://docs.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders

Можно ли будет статически привязать WinUI?

Это не то, что мы в настоящее время планировали - есть ли у вас сценарий, в котором это принесет пользу?

Скажем, мне нужно перераспределить его, каков размер WinUI примерно в МБ?

Мы все еще работаем над тем, как будет выглядеть окончательный граф зависимостей, но для частей пользовательского интерфейса он, вероятно, будет похож на соответствующие размеры существующих dll system32 (10 МБ).

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

Я думал, что nuget предназначен только для разработки, или я что-то упустил? Насколько мне известно, пакеты на основе nuget должны развертываться каждым приложением индивидуально и не могут использоваться совместно. Вот почему существуют специальные установщики для общей среды выполнения ядра dotnet, иначе в этом не было бы необходимости, учитывая, что пакеты ядра dotnet уже находятся на nuget ...

Вам не нужно устанавливать какие-либо инструменты разработки или SDK только для того, чтобы поделиться пакетами инфраструктуры пользовательского интерфейса. У WPF и WinForms для .NET Core была та же проблема, и они были вложены в создание общего пакета, чтобы людям не приходилось устанавливать SDK на компьютеры конечных пользователей , что, вероятно, стоит сделать и для WinUI, как только вы туда доберетесь (возможно, даже включите себя в комплект WindowsDesktop)

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

Для приложений, поставляемых из Microsoft Store, содержимое пакета выпуска также должно автоматически передаваться при развертывании.

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

Можно ли будет статически привязать WinUI?

Это не то, что мы в настоящее время планировали - есть ли у вас сценарий, в котором это принесет пользу?

Думаю, мне нужно уточнить: можно ли будет использовать WinUI в статически связанном EXE (который статически связывает VC-Runtime)? Я предполагаю, что это не должно быть проблемой из-за C ++ / WinRT, но я просто хотел убедиться ...

Скажем, мне нужно перераспределить его, каков размер WinUI примерно в МБ?

Мы все еще работаем над тем, как будет выглядеть окончательный граф зависимостей, но для частей пользовательского интерфейса он, вероятно, будет похож на соответствующие размеры существующих dll system32 (10 МБ).

Спасибо за информацию.

Потрясающая прозрачность, кстати, для такого огромного дела, мне это очень нравится.

Думаю, мне нужно уточнить: можно ли будет использовать WinUI в статически связанном EXE (который статически связывает VC-Runtime)? Я предполагаю, что это не должно быть проблемой из-за C ++ / WinRT, но я просто хотел убедиться

Это должно быть возможно (теоретически), но, как сказал @jesbis , мы все еще прорабатываем историю того, как распакованные приложения попадут в общую структуру. Возможно, нам понадобится установщик redist, как это делает .NET Core.

Обсуждение Windows 7 немного отвлекает, поскольку объем усилий (не говоря уже о стоимости) приведет к значительной задержке с WinUI 3.0. Срок службы Windows 7 заканчивается в январе, и мы призываем всех клиентов перейти на Windows 10. Мои клиенты могут не соглашаться с другими здесь, но даже Windows 8.1 не представляет для нас интереса.

Ты прав. Но мы не можем контролировать моего клиента, и в Китае более 60% систем - это win7. И мы не можем отказаться от этого рынка, поэтому мы не можем использовать какие-либо технологии, не поддерживающие win7.

Данные взяты из baidu, см. Https://tongji.baidu.com/data/os.

Но мы не можем контролировать моего клиента, и более 60% системы - это win7 в Китае.

TBH Я бы просто придерживался .NET Framework 4.8 + WPF, если вы застряли на Win7.

Но мы не можем контролировать моего клиента, и более 60% системы - это win7 в Китае.

TBH Я бы просто придерживался .NET Framework 4.8 + WPF, если вы застряли на Win7.

Но Win7 Sp1 может установить .NET Framework 4.8, а win7 без SP1 не может его установить.

Системные требования .NET Framework |

Если у вас даже нет SP1, значит, у вас уже истек срок эксплуатации 6 лет.

Поддержка Windows 7 RTM без пакетов обновления закончилась 9 апреля 2013 г.

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

Если вам нужна поддержка Windows 7, вам следует использовать технологию, которая уже поддерживает Windows 7, и не ожидать, что Microsoft решит эту проблему за вас.

@MarkIngramUK Не то, чтобы Microsoft решила эту проблему за меня, но я не могу поддерживать своих клиентов, которые используют win7 без sp1. Я не могу контролировать, чтобы наши клиенты использовали какую-либо систему, но те, кто использует win7 без sp1, откажутся от нашего приложения, а это означает, что мы потеряли этот рынок. Но мои конкуренты, которые не используют новую технологию, могут поддерживать win7 без sp1, и мои конкуренты выиграют этот рынок.

Печально, но факт: слишком много клиентов не заботятся о том, какие технологии мы используем, но им важно, чтобы приложение могло нормально работать на всех их устройствах.

Это статус-кво моей отрасли, и приведенные выше выводы могут не подходить для других отраслей.

@lindexi, как я уже сказал, нельзя ожидать, что новая технология будет перенесена на ОС,

@lindexi Я думаю, что если клиент не хочет использовать поддерживаемую технологию и предпочитает что-то устаревшее, то он не может разумно ожидать наличия современного пользовательского интерфейса. Эти два требования являются взаимоисключающими ...

@MarkIngramUK Грустно. Я думаю, что когда я смогу использовать сегодняшнюю новую технологию, эта новая технология стала старой технологией.

@lindexi - это прямо противоположно тому, что происходит. Вы не можете назвать новую технологию «старой технологией» только потому, что она не переносится на древнюю ОС. Если вам нужна поддержка Win7 (без SP1), используйте WinForms или MFC или что-то в этом роде.

@MartinZikmund Вы правы. На самом деле, наши пользователи почти не разбираются в компьютерных технологиях, даже win7 и win10 не могут отличить. Им все равно, какие технологии мы используем.

@jesbis Я бы с удовольствием

Со своими клиентами я использовал USB-накопитель (PenDrive) с Windows 10 Media и просто обновил его с Windows 7 до последней версии Windows 10 бесплатно. Они получили преимущества современной ОС с антивирусом, обновлениями Windows, Edge WebBrowser и поддерживают технологии графического интерфейса от старых, таких как WinForms, WPF, до более новых, включая UWP и выше (WinUI). Кроме того, вместо выключения я установил Windows в режим гибернации и научил пользователей просто нажимать кнопку питания, чтобы начать работу с ПК, и нажимать кнопку питания после завершения работы с ПК.
Также я помещаю ISO в Сеть, чтобы легко устанавливать / обновлять машины.

И у них есть то преимущество, что Candy Crush также предустановлен на своих компьютерах!

Мнение

Я думал, что реализации элементов управления WPF можно объединить в WinUI для поддержки старой версии Windows. (Например, Windows 7.) Но Microsoft слишком сложно реализовать это из-за офисной политики, лол.

Ответы

@lindexi
Я знаю, что сегодня в Китае много пользователей устаревших версий Windows. Но я считаю, что сегодня необходимо отказаться от пользователей Windows NT 5.x, и я знаю, что это сложно.

@MartinZikmund

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

В Китае необходимы как современный пользовательский интерфейс, так и поддержка старых платформ, если вы не хотите, чтобы ваша работа обслуживалась меньшинством. Итак, один из моих друзей, китайский разработчик, портировал Blink и V8 на Windows XP без установленных обновлений , многие разработчики используют его для реализации своих современных приложений. В Китае минимальные требования к версии операционной системы равны версии без установленных обновлений . Например, если вы знаете, что требование к версии операционной системы для приложения из Китая - Windows 7, в нем указано, что вы можете использовать приложение под «Windows 7 RTM» или «6.1.7600.16385 (win7_rtm.090713-1255)». Даже в мире Android многие приложения по-прежнему поддерживают Android 4.4.

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

PS Мы можем использовать последнюю версию Visual Studio 2019 для создания приложений для Windows XP RTM без установленных обновлений , с последним пакетом SDK для Windows 10 и последним стандартом C ++ 17 или пробуя C ++ 20 прямо сейчас. Из-за VC-LTL (https://github.com/Chuyu-Team/VC-LTL) и YY-Thunks (https://github.com/Chuyu-Team/YY-Thunks).

Заметка о себе

Большую часть времени я использую последнюю стабильную сборку Windows. (Сегодня я использую 10.0.18362. Я использую 19H1 и 19H2.) Но мои проекты Win32, разработанные для Windows Vista RTM без каких-либо установленных обновлений , и мои проекты UWP, разработанные для Windows 10 версии 1703 без установленных обновлений или более поздних версий из-за условного Поддержка XAML представлена ​​в RS2. (Мне нравится условный XAML. Почему его нет в Windows 10 Build 14393?)

Кенджи Моури

Пожалуйста, рассмотрите возможность распечатывания всех управляющих классов WinUI 3.0!

Насколько я понимаю, Microsoft решила запечатать все классы элементов управления UWP, потому что JavaScript (который не знает наследования) вызывал проблемы при использовании с унаследованными классами. Теперь, когда JS / HTML устарел, в новой структуре пользовательского интерфейса больше нет необходимости закрывать все классы. Отмена выбора упростит настройку элементов управления UWP, как это всегда было возможно в WPF. Также было бы очень полезно при написании настраиваемых элементов управления списком виртуализации или панелей иметь незапечатанный базовый класс виртуализации, от которого можно наследовать. Ни C #, ни C ++ / CX, ни C ++ / WinRT не имеют проблем с наследованием. Только неудача под названием JS / HTML заставила нас это сделать.

Поэтому, пожалуйста, удалите это ненужное ограничение при создании WinUI 3.0.

@gisfromscratch благодарим за отзыв! Мы определенно хотим поддержать разработку на C ++ (особенно с C ++ / WinRT).

Что упростило бы использование C ++? Вы пробовали C ++ / WinRT вместо CX?

Могут ли помочь другие примеры приложений?

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

Пожалуйста, рассмотрите возможность распечатывания всех управляющих классов WinUI 3.0!

@lukasf, это то, что мы, вероятно, собираемся сделать 🙂 В # 780 ведется связанное с этим обсуждение

@jesbis Я должен еще больше запачкать руки, используя C ++ / WinRT. Я просто следил за примером приложения Photo Editor C ++ / WinRT . Но когда вы внимательно читаете предоставленные ссылки, такие как привязка данных, вы попадаете во множество фрагментов C # и только некоторые побочные заметки, такие как «Для C ++ / WinRT любой класс среды выполнения, который вы объявляете в своем приложении, производный от базового класса, является известный как составной класс. И существуют ограничения, связанные с компонуемыми классами… ». Эта страница ориентирована на 95% C # и только 5% C ++.

@gisfromscratch спасибо! Мы будем иметь это в виду, работая над обновлением документации для WinUI 3.

Если это помогает, упомянутая вами страница привязки данных также ссылается на некоторые отдельные страницы, посвященные привязке данных с помощью C ++ / WinRT, например:

Элементы управления XAML;

Элементы управления элементами XAML;

В этом разделе также есть ряд других тем, относящихся к C ++ / WinRT.

Спасибо за отличную работу! Очень рад, что Xaml Island удален из WinUi 3.0.
Кстати: мне просто интересно, будет ли низкоуровневая реализация языковой проекции в WinUi 3.0 отличаться от компонента WinRT. Реализация языковой проекции компонента WinRT, похоже, сильно снизила производительность в проекте .NET UWP как во время компиляции, так и во время выполнения. Поскольку WinUi 3.0 полностью отделен от UWP, я надеюсь, что можно будет улучшить реализацию языкового взаимодействия.

@zenjia XAML Islands не удаляется из WinUI 3. WinUI 3 будет содержать API, которые позволяют приложениям WPF / WinForms / MFC размещать элементы управления WinUI 3.

Я пытался следить за прогрессом в WinUI. Раньше я пробовал писать приложения UWP на C #, но обнаружил, что это тяжелая битва. Но я очень хочу попробовать еще раз после winui 3.0.

У меня есть вопросы о дорожной карте winui. Вот четыре. Извините, если они были покрыты в другом месте. Я не нашел ответов, несмотря на долгие поиски ... дайте мне знать, есть ли лучший форум для того, чтобы задавать такие вопросы.

• Будут ли с открытым исходным кодом и обертки .net для собственных элементов управления? Неясно, является ли это репро github, которое отвечает за .Net сторону winui, учитывая, что единственный код C #, который я, кажется, нашел, предназначен для автоматических тестов. Я ищу такие вещи, как Microsoft.UI.Xaml.UIElement, но нигде не могу найти этот код.

• Когда мы дойдем до выпуска winui 3.0, будет ли модель приложения UWP и модель приложения win32 работать с одной и той же средой выполнения .Net Core? Я так и не понял, какая версия ядра .Net используется приложениями UWP. Я полагаю, что это что-то, что встроено в сами окна, и что Windows 10 SDK позволяет VS 2019 настроить таргетинг на правильную версию ядра .Net, доступную в UWP.

• Вопрос по Ксамльским островам. Есть ли шанс, что WPF и UWP могут использовать одно и то же воздушное пространство? Я не с нетерпением жду возможности решать проблемы с воздушным пространством, как мы это делали между winforms и WPF. Учитывая, что и WPF, и UWP построены на Direct-X, было бы замечательно, если бы они могли обмениваться пикселями друг с другом. Например, если бы у меня было закулисное меню на ленте (в WPF), которое должно было бы перекрывать остров xaml UWP, было бы замечательно, если бы это могло происходить без проблем. Не похоже, что мне нужно перепрыгивать через тонны обручей ради чего-то подобного. ... Я помню, что на заре WPF они пытались решить проблемы с воздушным пространством для клиентских приложений, которые хотели использовать элемент управления winforms "WebBrowser". Они опробовали функцию веб-браузера под названием «WebBrowser.CompositionMode», которая должна была позволить WebBrowser нормально работать с WPF. ... Но я думаю, что со временем от этой стратегии отказались. Возможно, взаимодействие между UWP и WPF могло бы быть настолько бесшовным, что они могли бы даже обмениваться пикселями друг с другом (в отличие от winforms и WPF). Одно из потенциальных преимуществ этого - позволить WPF расширить функциональные возможности элемента управления UWP. Например, WPF может наложить на остров xaml дополнительные визуальные элементы аналогично слою украшения. Это может пригодиться в крайнем случае.

• Есть ли шанс, что приложение WPF с островами xaml (скажем, 50% WPF и 50% WINUI) может когда-нибудь быть скомпилировано изначально для ARM64? Таргетинг на ARM возможен с приложениями, которые на 100% являются UWP, и было бы неплохо, если бы зависимости WPF не заставили бы нас отказаться от нашего родного таргетинга на ARM64. (Альтернативой может быть запуск приложения в режиме эмуляции x86, но это медленнее и ограничивает доступную память, которую можно использовать).

Надеюсь, все эти вопросы имеют отношение к дорожной карте winui. Любой совет будет принят во внимание.

Будут ли с открытым исходным кодом и обертки .net для собственных элементов управления? Непонятно, является ли это репро github, которое отвечает за .Net сторону winui, учитывая, что единственный код C #, который я, кажется, нашел, предназначен для автоматических тестов. Я ищу такие вещи, как Microsoft.UI.Xaml.UIElement, но нигде не могу найти этот код.

UIElement отсутствует в WinUI 2, поэтому в настоящее время его нет в репо. Он будет в WinUI 3, который еще не выпущен и не имеет открытого исходного кода, но мы над этим работаем!

Вы можете увидеть примеры в репозитории других собственных элементов управления, доступных для .NET через проекции WinRT, например, элементы управления WinUI 2.2, задокументированные здесь . В большинстве случаев им не требуются уже существующие файлы-оболочки для каждого языка, поэтому вы не можете найти файлы .cs в репо.

@ marb2000 может лучше всего прокомментировать вопросы об островах / рабочем столе.

Вопрос: _ Будет ли WinUI 3 UWP и Desktop использовать одну и ту же среду выполнения .NET? _
О: Да, это план. UWP и Desktop будут использовать .NET Core 3. Управляемые библиотеки WinRT будут использовать .NET Core 3 вместо .NET Native.

Вопрос: _Будут ли WPF и UWP находиться в одном воздушном пространстве? _
О: Хотя WPF и WinUI (и XAML UWP) кажутся похожими, на самом деле это не так. WPF использует DirectX9, а WinUI / XAML UWP использует Windows.UI.Composition для компоновки, рендеринга и анимации XAML (помимо современной версии DirectX11). К сожалению, это приводит к тому, что взаимодействие очень сложно. Ваше предложение об украшениях WPF интересно. Теоретически пользователь может создать всплывающее окно для размещения содержимого WinUI / XAML поверх содержимого WPF. Или он может сообщить визуальному дереву WPF, что требуется изменение макета, но все на основе HWnds.
@dbeavon Это хорошее предложение, вы можете создать для этого запрос функции?

Вопрос: _Скомпилируется ли приложение WPF с Xaml Islands в ARM64? _
О: Если .NET Core 3 для Windows наверняка поддерживает ARM64. Сегодня он поддерживает ARM32 в Windows. Однако в Linux поддерживается ARM64. Я думаю, что в дорожной карте .NET Core также есть поддержка ARM64 в Windows. Хотя AFAIN, даты пока нет. @richlander , есть новости?

@ marb2000

Вопрос: Будет ли WPF и UWP использовать одно и то же воздушное пространство?

Может ли UWP использовать Windows.UI.Composition для создания слоя, который может получить рендеринг из растрового изображения DirectX? Затем WPF отображает окна на этом слое, как win2d. Может быть, он может находиться в одном и том же воздушном пространстве. Но сложно заставить WPF отображать слой.

@lindexi Думаю, это может быть рай: D

Может ли UWP использовать Windows.UI.Composition для создания слоя, который может получить рендеринг из растрового изображения DirectX?

UWP Xaml имеет несколько способов визуализации растровых изображений DirectX или цепочек подкачки в Xaml и объединения их с Windows.UI.Composition, чтобы они использовали одно и то же воздушное пространство, включая SurfaceImageSource , VirtualSurfaceImageSource и SwapChainPanel - подробнее здесь:

https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop

Вы также можете вставить визуальный элемент Windows.UI.Composition в дерево пользовательского интерфейса Xaml UWP и нарисовать в нем содержимое DirectX, например, используя ICompositorInterop , ICompositionDrawingSurfaceInterop и ICompositionGraphicsDeviceInterop как описано здесь:

https://docs.microsoft.com/windows/uwp/composition/composition-native-interop

Эти подходы должны работать аналогично с WinUI.

Настольное приложение UWP сможет ссылаться на WPF / WinForm DLL и открывать окно WPF / WinFrom? Это позволило бы мне переходить постепенно.

@ marb2000 - .NET Core для Windows ARM64 находится в нашей дорожной карте. Сейчас я работаю над планом.

С WinUI 3.0 можно будет скомпилировать win2d поверх него?
(таким образом, отделив его от UWP)
Если так, это было бы безумно круто!

Мы все еще прорабатываем детали интеграции DirectX, но, надеюсь, можно будет обновить Win2D, чтобы использовать базовые классы WinUI вместо базовых классов UWP Xaml.

скрестив пальцы: D

извините, если это не по теме: отчеты об ошибках в UWP - можно ли добавить проблему на https://github.com/microsoft/microsoft-ui-xaml/ или где-нибудь еще?

извините, если это не по теме: отчеты об ошибках в UWP - можно ли добавить проблему на https://github.com/microsoft/microsoft-ui-xaml/ или где-нибудь еще?

@jtorjo отличный вопрос! Это репо - лучшее место для сообщений о любых проблемах, связанных с:

• API-интерфейсы UWP UI (например, Windows.UI.Xaml)
• Беглый дизайн
• WinUI

Как правило, в нижней части большинства страниц документации на docs.microsoft.com должна быть ссылка «Отправить отзыв об этом продукте», которая подскажет, как лучше всего

Для большинства аспектов UWP, помимо вышеизложенного, это будет заключаться в сообщении об ошибках в категории « Платформа разработчика » в Центре отзывов, в котором есть ряд соответствующих подкатегорий.

Будет ли WinUI 3 включать элемент управления UWP SemanticZoom? Я думаю, что это самый крутой контроль из всех.

@jesbis Спасибо! Только что опубликовал обсуждение System.IO

Даже Microsoft не отказывается от поддержки Windows 7 для Office, зачем же WinUI 3? Я имею в виду, что почти все серьезное программное обеспечение поддерживает Windows 7 (Photoshop, Office, Visual Studio 2019, VSCode, ...) Если WinUI не поддерживает Windows 7 ...

Даже Microsoft не отказывается от поддержки Windows 7 для Office, зачем же WinUI 3? Я имею в виду, что почти все серьезное программное обеспечение поддерживает Windows 7 (Photoshop, Office, Visual Studio 2019, VSCode, ...) Если WinUI не поддерживает Windows 7 ...

Office, вероятно, скоро прекратит поддержку, так как поддержка Microsoft Windows 7 закончится очень скоро. Но он построен на базе кода, который уже поддерживает Windows 7.

WinUI был построен на Windows 10, поэтому его необходимо будет снова перенести на Windows 7. Попытки сделать это не имеют смысла, если ОС переходит в конец срока службы, и поэтому людям придется перейти на Windows 10.

Вопрос: Будет ли WinUI 3 UWP и Desktop использовать одну и ту же среду выполнения .NET?
О: Да, это план. UWP и Desktop будут использовать .NET Core 3. Управляемые библиотеки WinRT будут использовать .NET Core 3 вместо .NET Native.
В: Будет ли WPF и UWP находиться в одном воздушном пространстве?
О: Хотя WPF и WinUI (и XAML UWP) кажутся похожими, на самом деле это не так. WPF использует DirectX9, а WinUI / XAML UWP использует Windows.UI.Composition для компоновки, рендеринга и анимации XAML (помимо современной версии DirectX11). К сожалению, это приводит к тому, что взаимодействие очень сложно. Ваше предложение об украшениях WPF интересно. Теоретически пользователь может создать всплывающее окно для размещения содержимого WinUI / XAML поверх содержимого WPF. Или он может сообщить визуальному дереву WPF, что требуется изменение макета, но все на основе HWnds.
@dbeavon Это хорошее предложение, вы можете создать для этого запрос функции?
Вопрос: Будет ли приложение WPF с Xaml Islands компилироваться в ARM64?
О: Если .NET Core 3 для Windows наверняка поддерживает ARM64. Сегодня он поддерживает ARM32 в Windows. Однако в Linux поддерживается ARM64. Я думаю, что в дорожной карте .NET Core также есть поддержка ARM64 в Windows. Хотя AFAIN, даты пока нет. @richlander , есть новости?

Итак, избавляемся ли мы от песочницы UWP? Что, в свою очередь, означает, что UWP в его нынешнем виде также уходит, а вместе с ним и защищенная песочница App Store, как мы ее знаем?

Итак, избавляемся ли мы от песочницы UWP? Что, в свою очередь, означает, что UWP в его нынешнем виде также уходит, а вместе с ним и защищенная песочница App Store, как мы ее знаем?

избавиться от песочницы UWP было бы безумно круто!

Это определенно не означает, что UWP уходит. Универсальная платформа Windows - это единственный способ создать нативную платформу для всего спектра устройств Windows (ПК, Xbox, HoloLens и т. Д.), И именно на ней Windows сосредотачивает свои инвестиции в собственной платформе. RE: песочница, в частности: изоляция контейнера приложений по-прежнему обеспечивает множество важных преимуществ для приложений и пользователей как UWP, так и настольных приложений.

Основные изменения:

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

Это означает, что для новых приложений вы сможете выбирать между UWP и моделями настольных приложений в зависимости от того, что имеет смысл для вашего приложения, и если у вас есть существующие настольные приложения (например, WPF, WinForms, MFC), вы можете постепенно обновлять их с помощью современных Функциональность WinUI с использованием Xaml Islands.

Итак, избавляемся ли мы от песочницы UWP? Что, в свою очередь, означает, что UWP в его нынешнем виде также уходит, а вместе с ним и защищенная песочница App Store, как мы ее знаем?

UWP будет одним из вариантов создания приложения WinUI 3.0. Использование UWP позволит вашему приложению работать на Xbox, Hololens и т. Д.

Но вы также можете создать приложение Win32 с WinUI 3.0 и получить доступ к API-интерфейсам UWP, но возможности запуска вашего приложения будут более ограниченными.

@mdtauk @jesbis Я полностью за UWP, но сейчас:

1. время компиляции безумно медленное! (в 6 раз медленнее, чем WPF - я использую целевую версию, сборка 1809 - сборка 17783)
2. Я знаю, что API перечисления файлов StorageFolder не является частью UWP, но это безумно медленно. Песочница UWP (по крайней мере, на рабочем столе Windows) больше вредит, чем помогает.
3. Конечно, асинхронное программирование - это весело, но в UWP, когда происходит исключение, оно каким-то образом съедается кодом UWP, а затем прерывается в отладчике с потерей всего контекста стека. Иногда у меня есть контекст стека внутри самого сгенерированного исключения, но не всегда.
4. Профилирование кода UWP практически невозможно. Событие dotTrace мгновенно ломается при попытке это сделать.

(Мне потребовалось больше месяца, чтобы перенести мой код из WPF в UWP, поскольку мне безумно нужна win2d, поэтому у меня нет возможности избежать UWP.)

@mdtauk @jesbis Я полностью за UWP, но сейчас:

1. время компиляции безумно медленное! (в 6 раз медленнее, чем WPF - я использую целевую версию, сборка 1809 - сборка 17783)
2. Я знаю, что API перечисления файлов StorageFolder не является частью UWP, но это безумно медленно. Песочница UWP (по крайней мере, на рабочем столе Windows) больше вредит, чем помогает.
3. Конечно, асинхронное программирование - это весело, но в UWP, когда происходит исключение, оно каким-то образом съедается кодом UWP, а затем прерывается в отладчике с потерей всего контекста стека. Иногда у меня есть контекст стека внутри самого сгенерированного исключения, но не всегда.
4. Профилирование кода UWP практически невозможно. Событие dotTrace мгновенно ломается при попытке это сделать.

(Мне потребовалось больше месяца, чтобы перенести мой код из WPF в UWP, поскольку мне безумно нужна win2d, поэтому у меня нет возможности избежать UWP.)

Было бы полезно опубликовать это в этой теме # 1517 и, надеюсь, вы можете включить имя кого-нибудь из команды SDK.

@jtorjo

время компиляции безумно медленное! (в 6 раз медленнее, чем WPF

Вы используете C ++ / WinRT? Если да, то используете ли вы предварительно скомпилированные заголовки?

@mdtauk только что отправил туда

@MarkIngramUK Это код на C #

Закрытие - пожалуйста, направляйте дорожную карту и альфа-отзывы по адресу: # 1531

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

Это действительно что-то в дорожной карте или было всего лишь предположением?

@mdtauk , @ zezba9000 все это теоретически возможно, и у нас в команде много опыта в области абстракции платформ. Как и во всем остальном, все сводится только к стоимости, графику и ожидаемой выгоде 😊

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

@andreinitescu Извините за тирады и жалобы, но только мои мысли из того, что я понимаю: хотя я буду использовать WinUI 3 для замены WPF только для Windows / Win32 ... Потому что WinUI в Windows использует только API рендеринга Windows, а не агностик Во-первых, WinUI, похоже, полагается на третьи стороны для повторной реализации / фрагментации (ugg) WinUI на других платформах (например, проект UNO, что круто, но, как и от Mono до .NET, является ненужным и тратит время на фрагментацию, если бы все было только разработан прямо с самого начала). Вместо использования портативного типа Skia или создания MS. Также не понимаю необходимости поддерживать 1% людей, которые не будут использовать C # с WinUI, что делает C # целью второго класса в определенном смысле и, что более важно, заставляет время разработки занимать намного больше времени. Так же, как Android использует Java + post-AOT для многих основных приложений, Windows должна использовать C # + pre-AOT. Потому что это экономит время. В конце концов, 70% ошибок с использованием C ++ связаны с освобожденными ptrs.

Отсутствие связи между группами в компании для долгосрочных сценариев использования, когда это будет становиться все более и более серьезной проблемой, когда они выпустят версию своей ОС Android для мобильных платформ (которую я планирую использовать), и все больше людей хотят на нее ориентироваться с инструментами MS ... чувствую, что это снова будет еще одна ситуация, похожая на WinPhone7. Термин Windows не следует больше связывать с ядром WinNT. Экосистема - это не одна платформа или одна компания, на которой она построена.

К сожалению, MS не может / не будет делать то, что Apple сделала почти 20 лет назад с переходом с OS9 на OSX. В том, что вы избавляетесь от повязки, переходя на ядро ​​UNIX / LINUX, НО имея встроенный в ОС эмулятор / симулятор для устаревшего программного обеспечения на следующие 5-10 лет, пока люди переносят программное обеспечение и инструменты разработки для запуска в исходном виде. (Думайте, что хотите, но я могу мечтать)