Runtime: Перенос System.Xaml в .NET Core

УРА! Официальное признание/признание! И да, я понимаю, что эти слова НЕ приравниваются к «приверженности», но это определенно лучше всего, что я видел до сих пор. @terrajobst ты мой герой. :сердце: :сердце: :сердце:

@cwensley и @SuperJMN , было бы здорово пообщаться между всеми здесь. В идеале (с моей точки зрения) каждый должен в конечном итоге использовать один порт/версию новой библиотеки Xaml и не иметь разных версий/диалектов Xaml. Возможно ли это хотя бы отдаленно? Я согласен с этим, если нет, но я хотел бы посмотреть, сможем ли мы, если да. :)

Кроме того, в настоящее время я нахожусь в «рабочем творческом отпуске (от властных клиентов, LOL)», и у меня есть 3-4 месяца, предназначенные для кросс-платформенного Xaml. Я мог бы буквально работать полный рабочий день и помогать в это время, если это необходимо. Что-нибудь для дела (а также, я оппортунист для удачного выбора времени!)

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

@ Michael-DST, я согласен, что наличие одного диалекта xaml важно. Однако реализация этого может быть совершенно иной. Стандартизация одной реализации на самом деле зависит от сообщества.

Для Portable.Xaml , который представляет собой порт PCL 259/136 отличной реализации Mono System.Xaml (лицензия MIT) с множеством исправлений. Идея состоит в том, чтобы поддерживать все, что делает MS System.Xaml (включая чтение/запись), используя один и тот же API, но не обязательно ограничиваться им.

В качестве примера расширенной функциональности Portable.Xaml поддерживает использование преобразователей типов для элементов в списке, где System.Xaml использует IList.Add(object), который вам придется реализовать с помощью пользовательской коллекции для поддержки различных типов.

@cwensley Я заявляю о своем невежестве в этом ... но в чем разница между .NET Core и PCL? Я думал они одинаковые? То есть, насколько я понимаю, если вы проектируете под определенный профиль PCL, он будет перенесен на .NET Core... это было некоторое время назад (и, честно говоря, я ждал, когда .NET Core станет RTM/W), так что сейчас хорошее время, чтобы обновить. :П

Насколько я понимаю/впечатление, Portable.Xaml действительно является портом Mono System.Xaml, в то время как OmniXaml является переписанным с нуля, который имеет некоторые новые преимущества на арене синтаксического анализа. В идеале (с моей точки зрения) было бы здорово как-то объединить их, но я даже не уверен, что это возможно или даже желательно между двумя базами. На мой взгляд (без анализа спелеологии) это в основном слияние зрелости одного (Portable.Xaml) с новой горячностью другого (OmniXaml).

Согласно этому сообщению , @Michael-DST PCL 259 действительно совместим с .NET Core. Я уже включил \lib\dotnet в качестве цели в пакет nuget для Portable.Xaml, поэтому его _должно_ можно использовать как есть для .NET Core, хотя я его не тестировал.

У меня не было времени изучать OmniXaml, но если это действительно переписывание с нуля, возможно, не имеет смысла объединять два проекта, поскольку я уверен, что все было бы сделано совершенно по-другому. Я также не уверен в пользе такой вещи, если Portable.Xaml в основном завершен как есть. Хотя могу ошибаться(;

:) Да, я изучаю варианты здесь, а также борюсь со своим невежеством, действительно находясь в мире с открытым исходным кодом. Я ненавижу идею иметь несколько кодовых баз, делающих одно и то же. И особенно с учетом того, что сообщество Xaml меньше, было бы отстойно, если бы оно было фрагментировано с самого начала (разве это не должно происходить _после_ того, что что-то становится слишком успешным для своего же блага?! ха-ха). В любом случае, было бы здорово услышать мнение @SuperJMN по этому поводу. Я знаю, что он казался довольно твердым в своих новых модификациях. Например, использование MarkupExtensionContext вместо IServiceProvider для расширений разметки, что было бы критическим изменением для любого, кто хочет перенести существующий код в этот новый мир.

Чтобы уточнить, все профили PCL совместимы с .NET Core. Наборы контрактов и факторинг, которые у нас есть сейчас, представляют собой эволюцию профилей PCL. Это не относится к переносимым библиотекам «старого стиля» (скомпилированным с помощью mscorlib и т. д.), которые не сразу совместимы с .NET Core.

@Майкл-DST

@terrajobst ты мой герой. :сердце: :сердце: :сердце:

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

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

Итак, считайте, что вы сделали то же самое, что просунули еду под дверь человека, запертого в одиночной камере почти на год. :stuck_out_tongue:

[Редактировать: прочитав эту аналогию (и увидев ее цитату ниже), я должен сказать, что она ужасна и, вероятно, на нее повлияла статья, которую я читал в то время — проклятые новости, почему вы должны так влиять на меня?! Лучше/актуальнее, вероятно, было бы получить столь необходимую инъекцию денег от ангельского раунда после года работы на перегаре.]

Копия: @Harikm86 , владелец System.Xaml

Я люблю XAML. Это отличный декларативный язык для всего: от Silverlight (да, я это сказал) до Windows Workflow, а теперь и до новой платформы Universal App. Перенос на Core позволит переносить другие технологии, зависящие от XAML. Нам это нужно!

Приятно слышать вашу поддержку @rschiefer! Спасибо за ваш вклад. Пожалуйста, убедитесь, что у вас есть другие разработчики Xaml, о которых вы знаете, которые присоединяются к этой теме и помогают с обсуждением/направлением.

Я также являюсь поклонником Silverlight и гонюсь за его следующим воплощением с 2011 года (бесстыдная вилка: если вы хотите, чтобы команда Visual Studio знала, что вы хотели бы увидеть следующую, более умную форму Silverlight, пожалуйста, проголосуйте и дайте им узнай здесь ).

Я хотел бы воспользоваться секундой и убедиться, что, когда мы говорим «Xaml», мы должны стремиться к системе/набору функций Xaml, найденным в .NET 4.x+ (или «System.Xaml»). На самом деле подойдет даже Xaml из Silverlight 5.

(Конечно, добавление новых улучшений, найденных в OmniXaml , также желательно.)

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

Я действительно даже не решаюсь назвать это системой «Xaml», так как это действительно XML с некоторым дополнительным разбором токенов на удачу (который явно нужен). Забавный факт: система Xaml UWP в конечном итоге использует сборку System.Xaml в процессе сборки. Ммм... #ирония.

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

Было бы неплохо вернуть Silverlight в более новом, лучшем виде. :) :) :) :)

@Майкл-DST

Итак, считайте, что вы сделали то же самое, что просунули еду под дверь человека, запертого в одиночной камере почти на год. :stuck_out_tongue:

Справедливо :smile:

@Майкл-DST

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

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

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

Извините, @terrajobst , теперь у меня есть новый герой в @rschiefer. :улыбка: :улыбка: :улыбка:

Спасибо всем за обсуждение. Для меня это очень круто (но меня легко впечатлить!).

@Майкл-DST

@helmsb ДА! ЛОЛ ха-ха!

FWIW, конкурентоспособная популярная технология Google Material Design для Интернета (Angular.js), приложений (Android) и т. д., также доступна с открытым исходным кодом. Надеюсь, этот аргумент поможет убедить боссов и боссоподобных сущностей.

@dsaf , что ты имеешь в виду?

FWIW Я упомянул эту проблему в статье, опубликованной сегодня под названием Is the Tide Turning on project.json? , посмотрите, как Xaml является предпочтительным механизмом для описания объектов .NET как с технической точки зрения, так и с точки зрения бизнеса/IP MSFT.

Ну все, как насчет сделки с Xamarin, а! что-то мне подсказывает, что в ближайшие месяцы эта проблема станет намного более занятой. :улыбка:

Не обязательно. Возможно, то, что мы видим, UWP Xaml или разновидность Xaml от Xamarin станет некой кросс-платформенной библиотекой. Это может означать, что ни порт System.Xaml, ни даже полностью управляемая реализация Xaml не могут быть реализованы.

Система Xamarin Xaml является закрытой/внутренней и далеко не такой зрелой, как System.Xaml. Сам код довольно хлипкий (признанная проблема с их стороны - фактическое использование этого является одной из причин, по которой он закрыт/внутренний). Кроме того, он тесно связан с BindingObject, что недопустимо, если вы хотите выполнить сериализацию POCO и т. д.

И, как указано выше, система Xaml UWP ужасна. Если только вы не знаете чего-то, чего не знаю я. :stuck_out_tongue:

Можете ли вы объяснить, что вы подразумеваете под «чисто управляемой реализацией Xaml»? FWIW, мое ожидание здесь не совсем прямой порт 1: 1 System.Xaml, а «новая» библиотека System.Xaml (Microsoft.Xaml?), которая берет все преимущества от System.Xaml, Xamarin.Core.Xaml, и... ну, я бы сказал Xaml UWP, но... :wink:

Я слышал, что внутренне предпочтение отдается Xaml UWP, а не WPF и тому подобному Xaml, хотя очевидно, что разные команды в Microsoft могут иметь разные мнения. Xaml от DotNet, без сомнения, более мощный и гибкий, но, как и все с этими дескрипторами, он, вероятно, имеет недостатки, которые являются причиной того, что UWP так сокращен.
И под не полностью управляемым я имею в виду одну приятную особенность Xaml UWP, заключающуюся в том, что он не является эксклюзивным для DotNet. Таким образом, потенциальное будущее Microsoft.Xaml может быть кросс-платформенной нативной реализацией с управляемым фасадом, чтобы его можно было использовать за пределами DotNet. (Это также исключает ее включение в dotnet/corefx, если эта будущая библиотека не будет решена для поставки в качестве компонента CoreFX)

Ладно, я в замешательстве. Когда вы говорите .NET... вы имеете в виду 4.6, верно? Насколько я понимаю, это для библиотеки .NET Core Xaml, которая по своей природе является кроссплатформенной и эксклюзивной для .NET (4.6)? Когда вы говорите «не эксклюзивно для DotNet», вы имеете в виду «включает ли DotNet»? Двойные отрицания. :stuck_out_tongue: Очевидно, это неправда, потому что вы не можете использовать UWP Xaml в .NET 4.6 (и вам не захочется :stuck_out_tongue:).

Пожалуйста, просветите меня, что я здесь не так. Кроме того, хорошей целью здесь было бы поставить Xaml как часть CoreFX. Некоторое обсуждение идет вокруг этого в течение некоторого времени . -- и, конечно же, если я не ошибаюсь, @RichiCoder1 , у вас есть свой голос, чтобы сделать именно это в этой теме... Мне было интересно, где я видел ваш тег раньше! :улыбка:

И я также хотел бы сказать, что я также слышал внутреннюю склонность к Xaml UWP, но это было до того, как вокруг него началось какое-то обсуждение в сообществе, начиная с этой ветки выше и далее ( аля обсуждение Тима Хойера в Твиттере ). С тех пор стрелка определенно сдвинулась. По крайней мере, было лучше! РЖУ НЕ МОГУ. Есть те, у кого неправильное представление о том, что «Xaml предназначен для пользовательского интерфейса», а есть и остальные, которые понимают, как это работает. :stuck_out_tongue:

Когда я говорю DotNet, я имею в виду DotNet, включая ядро ​​и структуру. И я понимаю, что вы не можете использовать UWP Xaml вне приложений UWP, я имел в виду возможность использовать его в приложениях C++ UWP. Поэтому, когда я говорю, что он не будет эксклюзивным для DotNet, я имею в виду, что собираюсь использовать его из C++ (или, возможно, из других языков). И я предполагаю, что причина, по которой команда, владеющая XAML, не рассматривает всерьез варианты использования за пределами пользовательского интерфейса, заключается в том, что они либо необычны, либо, в некоторых случаях, активно очерняются Microsoft или ее партнерами. Не мое личное мнение, я ценю его выразительность и мощь.

ОК, отлично @RichiCoder1 , спасибо за объяснение. Думаю, теперь я _почти_ полностью вас понимаю... когда вы говорите "фреймворк", вы имеете в виду 4.6?

На мой взгляд, я скажу, что одна из причин, по которой внутренняя команда считает, что использовать его вне пользовательского интерфейса необычно, связана с плохим взаимодействием с разработчиками, как я думаю, сообщение Тима показывает. Я также виновен в этом, потому что я действительно не смеялся над привлечением MSFT до года или около того назад? На самом деле твит Тима был о голосовании, которое я сделал после того, как я лично/частно жаловался всем, начиная с Windows 8.0, что система Xaml была совершенно другой и не такой, какой она должна быть. Когда я услышал слухи о том, что UWP (Windows 10) Xaml был в основном таким же — после 3 лет без инноваций или улучшений — тогда я активизировался. Оглядываясь назад, это должно было произойти гораздо раньше.

Можно с уверенностью сказать, что это был важный урок. Я (или, по крайней мере, чувствую, что я) теперь гораздо более интегрирован в экосистему и чувствую, что меня слышат. На самом деле, _очень важное_ голосование , которое я сделал чуть более четырех месяцев назад, было помечено авторитетной командой Visual Studio ранее на этой неделе как «На рассмотрении». Сказать, что мой мир был потрясен, это ничего не сказать. :улыбка:

По фреймворку я использую его для обозначения рабочего стола .Net. Кажется, это популярный способ отличить Core от Full Framework.

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

Сам очень взволнован этим! Теперь просто посмотреть, как это будет играть. Это может означать что угодно, от создания первоклассных инструментов Xamarin помимо приложений UWP, использующих их общие проекты, или это может означать что-то более высокое, чем даже это. Только время (и я думаю, //Сборка) покажет.

Хорошо, круто... спасибо за информацию. :+1:

Что касается //сборки... действительно. :) Лично я хотел бы увидеть совершенно новую модель, основанную (в общих чертах?) на UWP, и использовать новые преимущества Xamarin для переноса ее на iOS/Droid. Не помешала бы и более сильная модель Xaml. В конце концов, мы должны держать эту ветку в тайне до 28 апреля. :stuck_out_tongue:

Я надеюсь, что вы, ребята, можете это сделать! :)

Думаю, ребятам из UWP было бы легче внедрить реализацию XAML, которая не использует код .NET (даже если бы этот код был материалом .NET Core).

Как автономный черный ящик (или только в зависимости от UWP, но мы этого не хотим, поскольку UWP [пока] не является кроссплатформенным, и если бы это было так, то все равно пропустили бы его управляемую версию, которая могла бы работать в .NET/ Silverlight [не может заблокировать ваши приложения только для цели Win10]).

Но я думаю, что это более или менее утопично, если только вы не сделаете это с помощью уровня абстракции и подключаемых модулей/драйверов для различных приложений XAML (для пользовательского интерфейса UWP, для рабочего процесса, для WPF/.NET, для Silverlight и т. д.). Например, как DirectX кажется машиной через HAL (уровень аппаратной абстракции), что также открывает возможности для HEL (уровень аппаратной эмуляции — см. упоминания на http://www.developer.com/net/asp/article.php/968461/What -is-DirectX.htm). Конечно, если вы не будете осторожны, это также может открыть дверь в ад с точки зрения производительности, но поскольку DirectX может ее потянуть, я думаю, такая архитектура неплоха.

+1 за перенос System.Xaml на .NET Core.
Я надеюсь, что в будущем на всех платформах будет использоваться единый унифицированный диалект XAML (.NET Xaml, UWP Xaml, Xamarin Xaml).
Считается, что для этого необходима .NET Core версия System.Xaml.

+1

Чтобы избежать оповещений о массовых уведомлениях, у нас теперь есть новый способ +1 к отдельным комментариям на GitHub, чтобы показать наш интерес/реакцию на обсуждаемую тему:

Ха-ха @jasonwilliams200OK Я, например, не возражаю против массовых уведомлений от членов сообщества, выражающих их элементарный интерес к мощному кросс-платформенному решению System.Xaml. :angel: Возможно, в других темах я бы разделил вашу боль/раздражение/разочарование, однако. :подмигивание:

Верное (и ценное) замечание в любом случае. Я добавил свой :+1: по делу.

@jasonwilliams200OK

Спасибо, что назвали это!

FWIW, я только что пригласил команду Xamarin.Forms присоединиться к обсуждению здесь:
https://bugzilla.xamarin.com/show_bug.cgi?id=26740

Или, если что, пусть все _здесь_ знают о разговоре _там_. :улыбка:

В комментариях к этому посту разгорелась бурная дискуссия:
https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

По сути, JSON против Xaml для новой системы проектов, которая, похоже, разрабатывается для Visual Studio (ура!). Не стесняйтесь присоединиться. :) Так рад видеть, что это получает другой взгляд.

@Mike-EEE, также взгляните на эту дорожную карту: https://github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md. Новая проектная система на базе Roslyn будет очень ценной.

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

См. readme этого репо: https://github.com/dotnet/roslyn-project-system#welcome -to-the-roslyn-c-and-visual-basic-project-system (и ссылку на блог VS MSDN ), кажется, мы могли бы заменить различные компоненты с помощью MEF, что позволило бы вставить дополнительный сериализатор для разбора определения проекта, написанного на XAML. Лично я предпочитаю JSON XAML/XML, когда дело касается описания свойств проекта, зависимостей и т. д., поскольку JSON менее шумный (ну, YAML менее шумный, чем JSON, а стандарт lang поддерживает комментарии, в отличие от std-JSON, но в мире dotnet YAML и другие языки с синтаксисом, поддерживающим отступы, еще не набрали обороты)

Лично я предпочитаю JSON XAML/XML.

БЕЗОПАСНОСТЬ! УДАЛИТЕ ЭТОГО ЧЕЛОВЕКА!!! Хм, в смысле... :)

Я за то, чтобы брать лучшее из обоих миров. @SuperJMN и @Grokys могли бы говорить об этом больше, но я считаю, что в OmniXaml прилагаются усилия, чтобы сделать его менее многословным и болтливым.

Моя проблема с JSON связана не с JSON как таковым, а с его подходом к проектированию, который также был основой конфигурации .NET (который, я полагаю, был его источником вдохновения), и то есть схема объекта является «еще одним артефактом», который разработчик должен управлять/поддерживать и _не_ определение класса. То есть в программировании Xaml (как вы знаете!) определение класса _является_ схемой документа. В результате это придает очень естественное ощущение разработке документа, а также помогает с инструментами.

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

Другая проблема, с которой я столкнулся с JSON, опять же не связана с JSON, а больше связана с веб-мышлением и соглашением об именах. От этого пострадала и конфигурация .NET. То есть вы можете определить POCO, например:

public class MyPoco {
    public string Property {get; set;}
}

И его JSON (или app.config) будет выглядеть примерно так (и вы можете научить меня этому, если я ошибаюсь!):

{
 { "property": "Hello world I have inconsistent naming conventions!" }
}

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

Я должен сказать, что конфигурация .NET была САМОЙ ХУДШЕЙ, потому что ее дизайн дал четыре артефакта для каждой сущности конфигурации:

1. Элемент в web/app.config
2. Файл .xsd, который вы должны были каким-то волшебным образом связать с файлом web/app.config (у меня так и не получилось!)
3. Элементы ConfigurationElement и/или ConfigurationSection , которые брали значения из app/web.config (и сопоставляли несогласованный camelCase с PascalCase — о, безумие!)
4. POCO, который в конечном итоге был подключен из элемента конфигурации. (ВАУ!)

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

В любом случае Xaml улучшает этот дизайн, требуя всего два артефакта:

1. Файл класса (.cs)
2. Файл данных (.xaml)

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

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

Я думаю, что если вы рассматриваете атрибуты [DataContract] и [DataMember], то платформа .NET (на уровне BCL) помогает JSON и другим преобразователям данных. Однако компилятор не поддерживает нативных/низкоуровневых литералов объектов JavaScript <-> переход C# POCO, таких как JSON на JavaScript (и многие другие языки) или CSON на CoffeeScript. Однако, в отличие от XML со всеми его связями XPATH XQUERY XSLT, JSON имеет концепцию схемы для проверки данных, и JSON.net поддерживает ее как чемпион.

Для C# 6 и выше ознакомьтесь с этими вопросами/предложениями https://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+author%3Agafter+ словарь , особенно https://github.com/dotnet/roslyn/issues/6949 , и перейдите по ссылкам внутри. С новым синтаксисом инициализатора словаря C#6 и этим предложением кажется, что C# семантически становится более дружественным к JSON.

Я должен сказать, что конфигурация .NET была САМОЙ ХУДШЕЙ

Согласитесь, вам также могут понравиться шаблоны «Конфигурация» и «IOption», представленные командой ASP.NET в виде пакета plug and play: https://github.com/aspnet/Configuration , https://docs.asp.net/ en/latest/fundamentals/configuration.html , который заменяет старый печально известный менеджер конфигурации с привязкой к XML.

JSON имеет концепцию схемы для проверки данных, и JSON.net поддерживает ее как чемпион.

Звучит как определение класса как схема. :) :) :) :)

кажется, что C# семантически становится более дружественным к JSON.

Ха-ха, конечно, _любой_ объект уже поддерживает JSON. JSON отлично подходит для того, для чего он предназначен: записывать определения объектов в краткой, удобочитаемой форме. И нет никаких сомнений в том, что JSON.net отлично справляется с этой задачей. Когда вы переходите к описанию _приложений_, мы начинаем переходить к той области, где этот разговор начинает, гм, затрагиваться из-за отсутствия лучшего слова. :улыбка:

В конце концов, здесь есть два сценария (по крайней мере, для меня): описание объектов, предназначенных для передачи между границами службы (облегченный), и описание приложений, создающих эти объекты (значительный). Мне лично нравится стремиться к согласованности всеми возможными способами и свести к минимуму переключение контекста. Пока мы оставляем наши варианты ( IOptions ? :смеется:) открытыми и позволяем разработчикам выбирать формат, который им наиболее подходит (и позволяет им использовать инструменты, которые позволяют им чувствовать себя наиболее эффективными! ) то тут мы все выиграем. :+1:

UWP XAML имеет меньше функций по сравнению с классическим .NET WPF XAML. Одна из функций, по которой мне больше всего не хватает, — это TypeConverters.

Я попытался создать свой собственный TypeConverter, как предлагается здесь https://msdn.microsoft.com/en-us/library/bb546926 (v=vs.90).aspx (статья предназначена для WPF TypeConverters)

В UWP я получаю этот «автомобиль неизвестного типа» в пространстве имен XML « используя: App2TypeConverters »

        <ListBox>
            <local:car></local:car>
        </ListBox>

Неужели нельзя добавить собственный TypeConverter в UWP? Или есть обходной путь? Я где-то читал, что XamlCompiler использует внутренний IServiceProvider для регистрации TypeConverter. Может быть, его можно как-то зарегистрировать?
Мне также интересно узнать больше об истории компиляции XAML. Будет ли XAML по-прежнему генерироваться в BAML? Можем ли мы как-то подключиться к компиляции XAML?
Итак, пожалуйста, откройте System.Xaml.

Тааак... значит ли это, что System.Xaml наконец-то присоединится к вечеринке??? :улыбка: :улыбка: :улыбка:
https://blogs.msdn.microsoft.com/dotnet/2016/05/27/сделать-это-проще-для-порта-на-сетевое-ядро/

Я вклинюсь сюда и скажу:
а) Мне бы очень хотелось, чтобы XAML работал с .Net Core и
б) если , когда это произойдет, имеет смысл использовать вариант UWP, поскольку он уже переносится на другие архитектуры (например, IoT-подталкивание на Raspberry Pi).

Однако получить WPF XAML было бы замечательно, если бы это было возможно.

Точно так же, как ядро ​​.NET было по существу перестроено с нуля на основе последних десяти лет обучения, я думаю, то же самое следует сделать и для XAML. Эволюция WPF/Silverlight/WinRt-XAML обернулась полным провалом. Шаг вперед, два назад (один в сторону). Обещания XAML, Expression Blend и т. д. так и не были реализованы.

На днях я слышал, как Скотт Хантер оправдывал отсутствие кросс-платформенного пользовательского интерфейса в Dotnet Core, говоря: «Ну, они никогда не бывают хорошими. Пользователи Windows ожидают кнопку, похожую на Windows, на Mac — кнопку Mac». Ну простите - где он был последние 5 лет??? Интернет полностью доминирует в дизайне пользовательского интерфейса, и в Интернете нет такого понятия, как «стандартная кнопка», но знаете что? Пользователям удалось это выяснить. Этот аргумент просто противоречит всем доказательствам. Эти веб-интерфейсы теперь доминируют в коммерции на планете. Но, видимо, этого недостаточно для Dotnet Core. Почему мы не можем иметь кросс-платформенный XAML, не потворствуя любому [воображаемому] стремлению к «стандартному внешнему виду платформы»?

Я предполагаю, что основные технические препятствия заключаются в том, как связать «XAML» (или как там называется платформа пользовательского интерфейса следующего поколения) с кросс-платформенным 3D API, поскольку мы, очевидно, не можем зависеть от Direct3D/Direct2D в MacOS и т. д. Но я полагаю эта проблема была решена Unity и т. д., которым удалось достичь этой цели.

Microsoft так много тянула с открытым исходным кодом семейства технологий XAML, что возникает вопрос, скрыт ли в нем секретный кеш биткойнов или закрытые ключи к microsoft.com.

Продолжайте в том же духе MSFT: Open Source WPF/Silverlight/WinRT-XAML и начните новую золотую эру UX.

Удивительно слышать, что ты говоришь о Скотте Хантере, @JackUkleja. У вас есть источник/ссылка для этого? Если то, что вы говорите, правда, то в дополнение к тому, что вы говорите, это показывает (удивительно) невежество по нескольким направлениям:

1. Это именно то, что Xamarin.Forms пытался решить.
2. UX/взаимодействия/стили, зависящие от платформы (или имитирующие) — это проблема, которую можно и нужно решать с помощью тем. Это то, в чем WPF был очень хорош (хотя, по вашему мнению, его можно и нужно улучшить).
3. Хуже всего то, что это не вызывает доверия к кадровому резерву, успешно создавшему WPF, пожалуй, лучшую инфраструктуру для презентаций всех времен. Вы хотите сказать, что они больше не могут решить эту проблему? Или, по крайней мере, проделайте ту же магию, которая сделала WPF таким успешным в кросс-платформенной манере?

Хороший UX — это хороший UX. Как вы заметили, сеть наглядно демонстрирует это. Пользователи нативных приложений определенно привязаны к определенному внешнему виду своих нативных интерфейсов, но, опять же, это должно решаться с помощью темы.

Представьте, что вы можете просматривать приложение на устройстве iOS в «оболочке» Droid (вместе с поведением) и наоборот. Это было/возможно с WPF, и это именно то мышление, которое следует развивать в будущем. То есть внешний вид/ощущение/опыт не должны мешать разработке и дизайну приложения. Вы должны быть в состоянии применить тему, и whalah, "это просто работает". К сожалению, это было и остается хулителем Xamarin.Forms в том смысле, что, хотя он учитывает разные платформы, возникает много трений, связанных с обеспечением того, чтобы все работало должным образом на каждой целевой платформе.

@Mike-EEE Я почти уверен, что Скотт Хантер говорил об этом в эпизоде ​​с dotnet rocks: https://www.dotnetrocks.com/?show=1291

Ре:

«Кадровый пул, который успешно создал WPF, возможно, лучшую платформу для презентаций всех времен»

... насколько я понимаю, большое количество первоначальных архитекторов , некоторые из тех, кто занимался WPF, покинули MSFT, перешли в Google и были связаны с Angular. Многие идеи из WPF появляются в Angular и связанных с ним фреймворках, таких как шаблоны. Но независимо от того, как вы нарезаете эти веб-фреймворки, я думаю, вы всегда будете чувствовать запах HTML/CSS на заднем плане. Не все пользовательские интерфейсы имеют смысл быть основанными на документе/семантике, и это природа HTML, поэтому я считаю, что мир все еще может использовать «ядро XAML».

[джек... не думайте, что данные об архитекторах Google и WPF верны]

@rrelyea Это было мое понимание, но я могу ошибаться. Я мог бы поклясться, что читал, что некоторые из команды WPF работали над Angular… среди прочих, Ян Эллисон-Тейлор ? (Хотя кажется, что он вернулся в MSFT сейчас...)

запах HTML/CSS на заднем плане

Чем больше будет соответствия и конвергенции с унифицированными стандартами HTML CSS или любыми стандартами в этом отношении (C, C++, JavaScript), тем лучше будет этот мир. Вместо этого XAML с его уникальной функцией может отображать себя как расширенную структуру для стека HTML + CSS и т. Д. Или просто как альтернативный интерфейсный движок для Razor ASPNET: https://github.com/aspnet/Razor/issues/78 : лампа:

@jasonwilliams200OK FWIW/FYI уже есть «стандартный» порт HTML/CSS для .NET в JSIL . Весь его вывод на 100% совместим с HTML5 и работает в любом современном браузере. Это тот тип мышления, к которому мы должны стремиться, конечно (и это должно было быть мышлением после кончины Silverlight в 2011 году, но я отвлекся).

То есть (на ваш взгляд, я надеюсь) идеал/спрос заключается в том, что разработчики .NET должны иметь дело только с .NET/C#/F#/VB.NET и никогда не должны касаться CSS/HTML/JS, подобно тому, как Разработчикам Xamarin .NET не нужно касаться основ iOS/Droid (какими бы они ни были. :wink: ).

@Mike-EEE, в языках надмножества (от TypeScript до JavaScript или от Less до CSS) мы можем использовать языковой код подмножества в надмножестве в том же файле, но не наоборот. Таким образом, концепция надмножества немного выходит за рамки функций phonegap, cordova и т. д. :)

Ха-ха, да @jasonwilliams200OK Я просто хочу убедиться, что мы не создадим особый случай для нашего подхода/стратегии с возвращением .NET в браузер. К прикосновению к CSS/JS следует относиться с таким же пренебрежением, как к бинарному. :stuck_out_tongue:

Например, есть еще один проект Fayde , который использует Xaml (ура), но также зависит от TypeScript (бу). Это тот способ, которым НЕЛЬЗЯ делать это, поскольку в конечном итоге вы получите две несовместимые базы кода — одну в TypeScript/JS для клиентского кода, .NET для всего остального — что очень дорого как по времени, так и по ресурсам.

альтернативный внешний движок для Razor ASPNET

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

Я даже слышал некоторые комментарии от MS против специальных синтаксисов, подобных C #, таких как Razor, внутри HTML-страницы, в пользу фреймворков, которые вместо этого используют пользовательские теги.

Кстати, есть также Bridge.net (http://bridge.net) и другие компиляторы C# для Javascript, которые можно комбинировать с решениями XAML, такими как Fayde.

Re XAML на HTML5/JS/и т. д. Есть интересный проект Granular , который повторно реализует WPF. Он использует Saltarelle для компиляции в JS. Живой пример здесь .

Этот Granular просто фантастический, @ethanhs. Это было то, о чем я не знал. Поскольку он использует тот же подход CSHTML5 , JSIL, Bridge.net (о котором упоминает @birbilis ), он страдает от той же проблемы, заключающейся в невозможности совместного использования кода между сервером и клиентом посредством использования PCL, что на самом деле является единственным жизнеспособным. способ сделать это в наши дни.

И на самом деле, каким бы замечательным ни выглядел этот проект, он в значительной степени представляет собой ад, который пришлось пережить разработчикам .NET после закрытия Silverlight. Он и около дюжины других делают «нечто» для того, чтобы заставить .NET работать в браузере, но не совсем так, как ожидают те, у кого есть опыт работы с Silverlight.

До сих пор не существует единого, единственного объединяющего решения, которое заставит разработчиков забыть о Silverlight. Однако мы приближаемся. Я надеюсь, по крайней мере. WebAssembly кажется многообещающим, но я не видел/не слышал каких-либо значительных изменений в последнее время. Порт/инициатива, основанная на JSIL, кажется, несколько замедлилась и не регистрировалась с октября прошлого года.

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

Это было бы одним из лучших событий, произошедших с XAML за последние несколько лет.
Голосуйте здесь !

Круто @bbougot. Также есть еще одно голосование, которое _наконец-то_ привлекло внимание после почти 15 месяцев существования, не считая почти 3 лет нераспознания ужасной системы Xaml с самого начала (но я отвлекся!):
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

(Серьезно, 15 месяцев, чтобы хотя бы признать голосование по самой очевидной проблеме? Что там делает команда UWP??? Когда команда Visual Studio или .NET возьмет на себя управление и исправит ситуацию??? Что это будет . .. упс, верно, отвлекся...)

Также не забудьте проголосовать за эту тему. В настоящее время он работает довольно хорошо @ 60, особенно если учесть, что эта проблема началась до того, как у нас появились такие модные удобства, как GitHub Reactions. :улыбка:

Xaml — единственный, способный объединить всю клиентскую экосистему!
Пожалуйста, избавьтесь от DirectX, пожалуйста, примите OpenGL!
UWP должен работать на ПК, на телефоне, на веб-сайте!
Да здравствует Ксамл!

Итак, гражданский вопрос здесь @terrajobst , @harikmenon и @karelz (я вижу, вы недавно добавили тег, так что поздравляю, я втягиваю вас в это!). Из простого любопытства я решил немного рискнуть и проверить расширенную (а может и нет) фильтрацию GitHub в этом репозитории. Подумав, что голосов было много, а что не по разным вопросам.

Вот URL, который я использую:
https://github.com/dotnet/corefx/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

Похоже, что в настоящее время у этой проблемы 82 голоса, и если я прав, ближайший элемент в списке — 17. Это делает эту проблему, безусловно, самой запрашиваемой/за которую проголосовали за проблему в этом репо, верно?

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

Было бы здорово получить здесь какую-либо перспективу/контекст, и/или если я что-то совершенно неправильно понял в отношении потребительского спроса. Такое случается. 😄

Наши инженеры .NET Core уделяют большое внимание .NET Standard 2.0 (также высокий спрос со стороны клиентов) — см. подробности здесь и здесь . Мы рассмотрим другие библиотеки, не входящие в этот список, после того, как .NET Core будет соответствовать последнему стандарту.

Спасибо за указание на запрос upvotes!

Спасибо за ваш ответ @karelz! Очень признателен. 👍

👼 👼 👼 Я оставлю это прямо здесь на случай, если кто-то захочет поставить лайк или ретвитнуть. 👼 👼 👼
https://twitter.com/MikeEEE76/status/776769805722521600

Я работаю с xaml с версии 3 .net, я почувствовал уменьшение размера с помощью silverlight и даже его смерть. Я тот, кто любит изменения для улучшения, чтобы сделать вещи лучше и полезнее. Но теперь с UWP я нахожу регресс вместо того, чтобы двигаться вперед. Не обращайте внимания на все новые функции, которые, если они кажутся отличными, но в отсутствие полной поддержки xaml, как в настольном приложении. Я пытался создать новое приложение в UWP и на собственном горьком опыте понял, что все, чему я научился, снова изменилось, я не могу найти большую поддержку в сети, например, куда переместилась библиотека xaml. Например адорнера который был под фреймворком уже нет, x:static для свойств которые не работают, приходится часами искать пример или что делать. Нет ссылки, чтобы показать переход от старого xaml к новому UWP...

@giworking Очевидно, что MS должна обратить внимание на разработку клиента! Как цитируется Сатья Наделла, азуле — это ядро ​​и будущее MS. Самая мощная энергия для развития азуле — это вся экосистема .net. По сравнению с java, клиентская сторона является почти единственным оружием, позволяющим убедить программистов и бизнес принять облако MS (в Китае .net действительно находится в катастрофическом состоянии, люди говорят о java и реагируют: «Что такое fk s t xamarin?». ....). Итак, как китайский кодер, когда я вижу xamarin, uwp, typescript и cshtml5, я знаю, что можно объединить всю клиентскую часть в режиме xaml+C#, но почему наши друзья MS не видят возможности получить назад доля китайского рынка с если?

Вау, эта проблема уже набрала более 100 голосов! Большое спасибо всем, кто проявил свою поддержку. Если кому-то интересно, есть действительно ( действительно! ) отличная статья @terrajobst , дополненная его огромным участием разработчиков товарных знаков в комментариях здесь:
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introduction-net-standard/

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

В любом случае, определенно стоит прочитать, если вы еще этого не сделали, особенно комментарии. Это подводит меня к тому, почему я пишу сейчас, поскольку _Я очень рад видеть, что эта проблема упоминается в комментариях вместе со страстью/желанием привести System.Xaml в эру .NET Standard/кроссплатформенная_. 👍

154 голоса... и их количество растет. 😎 Для справки, следующий по величине выпуск — 25 . #скрипучее колесо

Это необходимо сделать. Давай!

У нас есть приложение @ReactWindows , ориентированное на WPF, в котором мы хотели бы использовать .NET Native, чтобы значительно улучшить процесс загрузки/установки при первой загрузке для десятков тысяч наших пользователей Windows 7. У нас также есть планы на будущее по внедрению React Native в Linux и возможному повторному использованию общего кода @ReactWindows, но нацеленным на Xamarin.Forms.

Наличие System.Xaml (и других зависимостей типов/методов/сборок WindowsBase, PresentationCore и Xamarin.Forms), доступных в NETCore vNext, имеет решающее значение для этой стратегии. Мы можем обойти этот недостаток, повторно создав и перенацелив существующие сборки, или заполнив отсутствующие типы/методы в System.Xaml Mono и создав его для .NET Core, но на самом деле мы бы предпочли, чтобы Microsoft активизировалась и предоставила то, что есть. необходимо для платформы.. /cc @rozele @pre10der89

@matthargett Удачи в этом. Я победил эту проблему до смерти, когда искал перенос рабочего процесса в ядро ​​.net. Даже зашел так далеко, что связался с командой xaml. Они даже отдаленно не заинтересованы в открытии System.Xaml. Я не понимаю почему - там точно нечего защищать.

Возможно, это будет рассмотрено после выхода версии 2.0 в конце апреля.

Ребят, опять же нам не нужен System.XAML, чтобы портировать WF на netstandard1.x ... Уже есть хорошая работа от @dmetzgar, в которой работает ядро ​​WF. Основной недостающей частью являются транзакции, которые, как мне кажется, в конечном итоге вернутся в netstandard2.x .

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

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

Существует OminiSharp, который можно использовать для разработчиков XAML, но опять же, дизайн/сериализация выходит за рамки ядра WF. Он должен быть тонким, как и все остальное с .Net Core.

Я бы сказал, что эта проблема громко заявляет о том, что люди хотят перенести WF на .Net Core, я просто думаю, что жаловаться на OSS с командой System.XAML просто непродуктивно. У команды XAML другие приоритеты, и он является основным для бизнеса Windows/UWP/Xamarin, поэтому не ожидайте, что он так скоро получит OSS. Вместо этого я бы попросил @dmetzgar официально опубликовать репозиторий WF в рамках .Net Foundation и помочь сообществу запустить его, не устанавливая никаких сроков или обещаний по завершению выпуска за netstandard2.x . Это будет постоянная работа, которой будет управлять его команда, и в основном помогать сообществу, которое явно хочет помочь и разобраться.

Посмотрите, как быстро развиваются события в проекте «Орлеан»… В прошлом году это был исследовательский центр Microsoft, который получил OSS, и это один из крупнейших и наиболее активных репозиториев в .Net Foundation, и он в основном поддерживается усилиями сообщества (у него все еще есть Команда MSFT работает в ней полный рабочий день).

В любом случае, ИМХО, я думаю, нам нужно перестать болтать и начать что-то делать. Понятно, что у команды @dmetzgar нет пропускной способности, чтобы работать над этим, поскольку их главная забота — поддержка основных пользователей WF, которые в основном представляют собой крупные развертывания Sharepoint, которые вообще не планируют переходить на .net core. Таким образом, это должно быть усилие сообщества (под контролем команды @dmetzgar ).

Ребята, повторюсь, нам не нужен System.XAML, чтобы портировать WF на netstandard1.x...

@galvesribeiro это может быть правдой, но проблема заключается в переносе System.Xaml в .NET Core, из которых это, безусловно, самая востребованная функция в репозитории, где команда .NET запрашивает отзывы. Если вы не прислушиваетесь к своим отзывам, то зачем их запрашивать? В любом случае, WF — это просто _один_ из сценариев, которым удовлетворяет порт System.Xaml. Как вы знаете (или должны!) System.Xaml способен на гораздо большее.

У команды XAML другие приоритеты, и он является основным для бизнеса Windows/UWP/Xamarin, поэтому не ожидайте, что он так скоро получит OSS.

Да, это своего рода проблема, и мы просим изменить ее. :) Кроме того, я даже не уверен, что в наши дни существует «команда Xaml», не так ли?! Действительно кажется, что эта технология была закрыта, и мы начинаем обходить ее стороной.

В любом случае, ИМХО, я думаю, нам нужно перестать болтать и начать что-то делать.

100% согласен. FWIW, @SuperJMN только что выпустил OmniXamlv2.0 , так что в настоящее время предпринимаются некоторые усилия сообщества, которые можно использовать, в то время как MSFT уделяет приоритетное внимание своей энергии и усилиям по этой проблеме (которые, кстати, продолжаются уже около 11 месяцев - и подсчет).

Говоря об этом, вот хорошая ветка именно об этом (то есть о бездействии MSFT в этом) с цитатой @terrajobst :

Чтобы было ясно, я не говорю, что System.Xaml не может или не должен быть кроссплатформенным. Я говорю о том, что System.Xaml не очень полезен вне WPF и WF, а NuGet — разумная прокси-метрика для этого оператора. Конечно, System.Xaml можно сделать осмысленным за пределами области пользовательского интерфейса, но это второстепенный шаг. Я предпочел бы использовать наши ресурсы ПРЯМО СЕЙЧАС, чтобы основные части работали хорошо и завершились. Кроме того, при наличии конвергентной базы перенос компонентов более высокого уровня, таких как System.Xaml, также становится намного проще.

Так что это не утверждение «или-или»; это заявление о порядке исполнения.

Отбросив в сторону очень неверное утверждение о том, что System.Xaml бесполезен вне WPF/WF, все это звучит для меня как менеджер проекта, без намерения когда-либо решать эту проблему. Моя цель не в том, чтобы критиковать это заявление, поскольку я полностью поддерживаю Иммо и ту огромную работу, которую он здесь делает. Тем не менее, я был достаточно близок, чтобы позволить такого рода формулировкам заставить меня задуматься и поставить меня в выжидательную позицию (или, скорее, «поверьте, когда я это увижу», LOL!) Позиция в отношении этого вопроса.

А пока я поддерживаю текущую работу над .NET Standard 2.0 и с нетерпением жду результатов. Может быть, это может быть лучше, чем ожидалось. По крайней мере, похоже, что мы сможем восстановить System.Xaml для проектов .NET Core, работающих на платформах Windows, что для меня достаточно хорошее начало. 👍

@Mike-EEE, во-первых, извините... Хотя я отвечал на это https://github.com/dotnet/corefx/issues/2394 oO Эти две проблемы слишком часто коррелировали, что я запутался.

Во-вторых, я никоим образом не утверждаю, что XAML полезен только для пользовательского интерфейса. Я использовал его в течение многих лет в сборках TFS, WF и в последнее время для пользовательского интерфейса. Существует множество DSL, таких как Azure ML и другие, которые могут использовать XAML.

Я хотел сказать, что не вижу, чтобы XAML так скоро переносили на .Net Core. Как сказал Иммо, им нужно сначала разобраться с текущими платформами. В .Net Core пока нет даже собственных библиотек для работы с изображениями.

Существует множество реализаций XAML, начиная от полнофункционального WPF и заканчивая слабыми и не имеющими большого количества функций в UWP. Его нужно унифицировать и стабилизировать, прежде чем такая штука получит OSS. Я не говорю о командах, работающих в нем. Я просто думаю, что я бы не стал делать diff, чем они, если бы мне пришлось расставлять приоритеты в своих ресурсах.

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

Эти две проблемы были связаны слишком много раз, что я запутался.

Ха-ха @galvesribeiro Я не могу вам сказать (или боюсь признать), сколько раз это меня тоже кусало. Не беспокойтесь об этом. Я, например, ценю вклад независимо!

FWIW, также похоже, что @cwensley продолжает отлично работать над @ Portable.Xaml , недавно улучшив производительность своей моно-адаптации System.Xaml , которые делают его быстрее, чем исходная версия. Почти кажется, что это может быть хорошей отправной точкой для усилий здесь, поскольку это, вероятно, ближе всего к исходному опыту System.Xaml со всеми вариантами/параметрами. Просто мои два цента, вызванные кофеином, за утро.

Перенесите System.Xaml на .NetCore.

FWIW, более 200 голосов за эту проблему, теперь она находится на 202-м месте. Следующей по величине проблемой является dotnet/corefx#13526, находящаяся на 47-м месте. Ну, WAS 47... теперь 48-е после моего голосования. :) (Иди, покажи ему немного любви, это хорошая идея.) #squeakywheel

Спасибо за напоминание @Mike-EEE ;-). Чтобы установить ожидания: мы еще не готовы начать глубоко копаться в этом - я лично надеюсь, что к марту мы сможем больше прокомментировать наши следующие официальные шаги, даже если это снова «у нас пока нет планов» (отказ от ответственности: я пытаюсь сообщить свое личное предположение, пожалуйста, не рассматривайте это как официальное обещание команды!).

Когда мы немного обсуждали эту проблему в прошлый раз, ключевой вопрос, который возник, заключался в том, чтобы определить, какое из более чем 200 голосов действительно относится только к System.Xaml или WPF. Предполагается, что многие люди не различают их. Любое предложение, как лучше всего это сделать? (например, создание 2 конкретных проблем и просьба к людям голосовать за WPF против «чистого Xaml, а не WPF»)

Также было бы полезно иметь сводный список сценариев для System.Xaml с некоторыми оценками приоритета (сейчас они разбросаны по долгому обсуждению). @Mike-EEE, ты не мог бы помочь нам собрать это, пожалуйста? (поскольку вы, кажется, имеете большой интерес и глубокие знания в этой области)

Определенно System.Xaml — это то, чего хотят люди @karelz. Если кто-то думает о WPF здесь, это не то место, ИМХО. Есть множество других фреймворков, использующих XAML, таких как WF, TFS Build и т. д., которые по-прежнему используют System.Xaml, и это могло бы нам помочь.

@karelz Я очень ценю ваш ответ здесь. Спасибо, что нашли время сделать это. Как упоминает @galvesribeiro , System.Xaml — это больше, чем просто пользовательский интерфейс, что, по-видимому, является ключевым пониманием, которое, к сожалению, упускается многими MSFT. Это мощная парадигма сериализации, которая ставит ее выше любого другого решения для сериализации, особенно когда дело доходит до описания приложений, что она делает лучше всего (в конце концов, буква «А» в ее прозвище). К сожалению, «приложение» было объединено с «UI» и, следовательно, здесь возникают трения.

Игнорирование этого аспекта было ключевым недостатком UWP и является одной из причин, по которой никому не нравится работать с ним. И наоборот, Xamarin, кажется, понял этот ключевой аспект в своей разновидности Xaml, но он является внутренним и не выставляется как первоклассное авторитетное предложение (что в значительной степени является тем, о чем здесь идет речь).

TBH , порт @cwensley System.Xaml в Portable.Xaml , кажется, на данный момент является лидером. Он не только портировал System.Xaml от Mono (сохранив его в целом знакомый API), но и добавил новые функции и фактически улучшил его производительность, чтобы она стала _лучше_, чем у System.Xaml.

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

Помимо этого, это становится сложным и может добавить к вашему (по понятным причинам) сложному взгляду на эту проблему. Поскольку System.Xaml предоставляет выразительный и мощный язык для описания приложений (опять же, не только пользовательских интерфейсов), он также имеет отличную поддержку инструментов, встроенную в Visual Studio (и, конечно же, Blend). Так что в идеале было бы здорово продолжить тот же замечательный опыт и каким-то образом сохранить возможности дизайнера Xaml в кросс-платформенной манере, но лично это требует вишенки на торте, который мы здесь обсуждаем. :)

Кроме того, повторяю здесь, обещание (и реализация) Xaml также было улучшением рабочего процесса разработки между дизайнером и разработчиком. Мне нравится думать, что в конечном итоге мы можем сделать еще один шаг вперед и улучшить процесс между разработкой и _devops_. То есть я хотел бы увидеть мир, в котором devops работает в красиво оформленных редакторах конфигурации приложений (на основе Xaml) для управления и поддержки развернутых приложений.

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

Я делюсь этим с вами в качестве перспективы видения, просто чтобы вы знали. Однако я не уверен, насколько вам интересно это слышать. 😉 Итак, если это просто "что нужно сделать, чтобы закрыть этот вопрос и заставить вас уйти?" Я бы предложил изучить возможность работы с г-ном Уэнсли и посмотреть, сможем ли мы использовать его большую работу на данный момент (и если он вообще открыт для этого). Если есть способ изменить это так, чтобы он мог стать авторитетным кроссплатформенным пакетом Xaml для выпуска .NET Core Wave 2 (примерно в мае или около того?), тогда даже лучше. :)

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

Да, меня определенно интересуют подробности. Я не думаю, что кто-то оспаривает Xaml!= WPF на стороне MSFT. Я точно не пытался это сделать. Я просто знаю, что я не совсем понимаю, и я пытаюсь заполнить пробелы, т.е. полностью понять мотивацию и необходимость сценариев "чистого Xaml".
(Кстати: я не совсем понимаю ваш сценарий devops и как Xaml является единственной/лучшей вещью, которая может помочь там? Или как он вообще используется в сценарии?)

Я здесь не для того, чтобы пытаться закрыть этот вопрос. Пожалуйста! Это даже не приходило мне в голову. Я здесь, чтобы помочь сообществу обобщить запрос, чтобы его можно было обсудить с нужными людьми (в данном случае с директорами). Да, отчасти это означает, что я (и/или пара других MSFT) должны полностью понимать просьбу представить ее выше — отсюда и мои вопросы.

Признаюсь, я хороший пример человека, который не различал Xaml и WPF до того, как увидел эту проблему. Из случайных чатов с другими членами команды .NET многие знают, что Xaml != WPF, но они не видят «огромной ценности» наличия чистого Xaml, который здесь представлен, поэтому мои вопросы выше о сценариях. Сценарии помогут мне/нам лучше понять мотивацию и лучше рассказать/продать историю. (Надеюсь, неудивительно, что когда нет четкой истории, никто не хочет ее финансировать :) - история является предварительным условием для финансирования)
Итак, давайте придумаем презентацию для лифта, чтобы продвинуть ее вперед.

Что касается работы @cwensley - приятно слышать, что могут быть не такие дорогие решения. Но опять же, было бы действительно полезно сначала понять предысторию и ПОЧЕМУ, прежде чем мы перейдем к решению. Я надеюсь, что это имеет смысл. (Я не пытаюсь быть пренебрежительным или что-то в этом роде - просто повторяю, что легче двигаться вперед, когда ПОЧЕМУ понято и согласовано)

@galvesribeiro Если кто-то думает о WPF здесь, это не то место, ИМХО

Я не разделяю вашей уверенности в том, что все 200+ проголосовавших людей действительно понимают Xaml != WPF до таких деталей. Также я думаю, что по крайней мере некоторые смотрят на это - да, давайте сначала получим Xaml, тогда будет проще попросить WPF. Так что их сценарий все время в голове - это WPF, а "чистый Xaml" - это только первый шаг к нему.
И, возможно, я ошибаюсь (хотя я, по крайней мере, не единственный человек в команде .NET с такими сомнениями)...
Другой подход может заключаться в том, чтобы разбить «чистый Xaml» на список сценариев (WPF, devops выше, может быть, еще несколько?), а затем попросить людей проголосовать за них — какие из них действительно важны для тех, кто проголосовал здесь? Чего они действительно хотят?
(Это не тактика задержки или что-то злое, я пытаюсь понять здесь «клиента». Я надеюсь, что это имеет смысл - если у вас есть лучшие предложения, как получить такие данные, говорите, я открыт для альтернативных подходов )

РЕДАКТИРОВАТЬ: Как обычно, если вы думаете, что я неправильно подхожу к проблеме, скажите об этом. Я пытаюсь сделать все, что в моих силах, чтобы помочь - из лучших побуждений. Я не страдаю от иллюзии всезнания или мысли, что я умнее всех остальных.

@karelz Существует множество фреймворков пользовательского интерфейса, которые заново изобретают колесо и пишут свои собственные языки разметки только потому, что XAML не является кроссплатформенным, даже если им вообще не нравится WPF. Авалония — одна из лучших. Они используют Omnisharp вместо собственного XAML.

Workflow Foundation является крупным пользователем/покупателем XAML, и люди в потоке Port WF to .Net Core всегда спрашивают об этом.

Так что да, я согласен с вами, что мы должны установить ожидания или нарисовать необработанный набор функций на основе того, что ожидается от кросс-платформенного System.Xaml , а также желаемого использования, такого как, например, пользовательский интерфейс и WF.

@карелз

Также я думаю, что по крайней мере некоторые смотрят на это - да, давайте сначала получим Xaml, тогда будет проще попросить WPF. Так что их сценарий все время в голове - это WPF, а "чистый Xaml" - это только первый шаг к нему.
И, возможно, я ошибаюсь (хотя я, по крайней мере, не единственный человек в команде .NET с такими сомнениями)...

Так... в чем проблема? Кроссплатформенное решение наподобие WPF могло бы быть неплохой вещью. Xamarin не может создавать кроссплатформенный графический интерфейс рабочего стола.

@jnm2 jnm2 это неплохо, но если это основной (90%+) сценарий, мы должны запланировать оба варианта. Наличие Xaml без WPF в таком случае не поможет (по крайней мере, не сильно). И это может создать (потенциально) неверную иллюзию того, что WPF зафиксирован и появится вскоре после этого.

Внедрение WPF/GUI в .NET Core станет огромным шагом для .NET Core, который сейчас нацелен в основном на серверные сценарии и консольные приложения.

@jnm2 наличие System.Xaml очень помогло бы людям (таким как я), которые _пытаются_ внедрить что-то вроде WPF на другие платформы (https://github.com/AvaloniaUI/Avalonia).

@grokys , это звучит как разумный сценарий - не могли бы вы рассказать об этом подробнее? Насколько масштабной будет помощь? Что сложного без этого?

Я также использую Xaml для своей (не WPF-подобной) кросс-платформенной среды пользовательского интерфейса рабочего стола, Eto.Forms . Вот почему я с самого начала создал проект Portable.Xaml , и до сих пор он хорошо работал для меня и моих пользователей.

Я не против помочь сделать это «авторитетной» кросс-платформенной реализацией xaml (как выразился @Mike-EEE). Однако имейте в виду, что я работаю над этим только в свободное время (;

@карелз
Не только фреймворки пользовательского интерфейса, он может использоваться во многих сценах, таких как XAML в HTML.

@Kation , можете ли вы поделиться более подробной информацией, что именно вы имеете в виду?

Кстати: я начал обобщать сценарии в верхнем посте - если вашего сценария там нет, опишите его, и как только он будет понятен, я добавлю его туда.

@карелз
С помощью мощного редактора XAML в Visual Studio мы можем быстро создавать содержимое пользовательских компонентов.
Затем, я думаю, мы могли бы использовать XAML для генерации содержимого HTML в каком-то специальном сценарии, даже больше содержимого SVG.
Это полуфабрикат XAML в XML для .Net 4.5. https://github.com/Kation/Веб-презентация

Я не понимаю, почему вы хотите генерировать HTML или SVG из XAML. Какова ценность XAML здесь?
Ценно ли то, что у него есть хороший редактор VS? Существуют также HTML-редакторы, почему бы не использовать их напрямую?
Или я вообще упускаю суть?

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

@karelz еще раз спасибо за диалог. Я, например, очень ценю это.

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

О, я завидую. 😉

Так что их сценарий все время в голове - это WPF, а "чистый Xaml" - это только первый шаг к нему.

Да, это снова путаница, о которой я упоминал. Xaml — это парадигма сериализации, чистая и простая. В нем вы можете определить и описать приложение и содержащиеся в нем компоненты. Для начала вот пример _консольного приложения_, описанного на Xaml:
https://github.com/DevelopersWin/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

Вы можете видеть, что в Xaml есть команды, которые предоставляют инструкции о том, что представлять пользователю с помощью ввода и вывода консоли. Это не имеет ничего общего с WPF или «UI» (хотя технически это пользовательский интерфейс в том смысле, что CLI является пользовательским интерфейсом, но, надеюсь, вы сможете заметить разницу). Кроме того, вы можете видеть, что я использую расширения разметки и объявления статических элементов прямо в файле. Это то, чего я не видел в JSON или любом другом формате данных. Это действительно сила Xaml, IMO.

В качестве еще одного примера сценария «Pure Xaml» вот файл, который я предлагаю для новой независимой от формата MSBuild:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Processor.xaml

(если вы подниметесь на уровень выше, вы увидите другие форматы, которые делают то же самое, просто это версия Xaml)

Это файл процессора, который снова представляет собой набор ( System.Windows.Input.ICommand ) команд, описывающих шаги, которые необходимо предпринять в теоретическом процессе сборки. Опять же, нет WPF или пользовательского интерфейса, но вы можете видеть, что он выводит сообщения на консоль.

Здесь я хочу отметить одну особенность, о которой я упоминал ранее, — это встроенный в Visual Studio инструментарий, который я получаю из этого файла:

Не выполняя никакой работы и не определяя какую-либо внешнюю схему, Visual Studio просто «загорается» и предоставляет редакторы свойств с раскрывающимися списками и другим интерфейсом дизайнера на основе схемы класса файла, с которым я работаю (надеюсь, это упростит сценарий devops). чтобы понять).

В дополнение к файлу процессора, вот теоретический проект или входной файл, который можно использовать для отправки в процессор:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Project.xaml

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

Кстати, этот пример кода полностью работоспособен, поэтому вы сможете получить SLN из этого репозитория и запустить версию Xaml, результаты должны выглядеть примерно так:

(Примечание: работает на моей машине , поэтому ваш пробег может отличаться. 😄)

Кстати: я не совсем понимаю ваш сценарий devops и как Xaml является единственной/лучшей вещью, которая может помочь? Или как это на самом деле используется в сценарии вообще?

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

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

Итак, по сути, то, о чем мы здесь говорим, — это разработка на основе POCO, где редактирование и проектирование происходят на POCO, используемых в процессе приложения. Как мы знаем, разработчик и дизайнер будут работать с файлом Xaml, описывающим элементы POCO, которые имеют дело с доменом пользовательского интерфейса (если хотите, это традиционный «WPF» для «Xaml»).

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

Вы можете думать об этом как о живых файлах конфигурации. То, как они загружаются, нужно будет сгладить, но конечный результат будет примерно таким, как вы видите на снимке экрана выше в Visual Studio. Вместо того, чтобы конечный (devops) пользователь был вынужден вкладывать свои руки в код (или, скорее, организация была вынуждена нанимать дорогой талант/набор навыков, необходимый как таковой), они вместо этого работают с ограниченными, проверенными средствами визуального редактирования для настройки и поддерживать приложение.

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

Один аспект, который я не упомянул об этом, заключается в том, что эти элементы управления на самом деле можно настраивать. Visual Studio имеет обширный (хотя и устаревший) API для определения визуальных редакторов, прикрепленных к этим свойствам POCO:
https://msdn.microsoft.com/en-us/library/microsoft.windows.design.model.designmodevalueprovider(v=vs.90).aspx

Все это доступно прямо сейчас в Visual Studio без какой-либо дополнительной работы, накладных расходов или усилий. Таким образом, конечной идеей здесь будет создание набора мощных редакторов и дизайнеров, которые будут помогать не только в процессе разработки, но и, в конечном счете, в процессе devops.

Опять же, все это иллюзорно и без какой-либо реальной реальной основы (пока). Конечно, это не совсем моя идея, но она вдохновлена ​​группой шаблонов и практик с их редактором конфигурации на основе Windows Forms . Я просто сделал еще один шаг вперед и увидел, как это можно использовать с помощью Xaml.

Пожалуйста, дайте мне знать, если у вас возникнут дополнительные вопросы по поводу этого @karelz. Опять же, я ценю диалог. Это не только дает возможность поделиться, но также дает возможность проверить мои идеи и убеждения. И, возвращаясь к идее всезнания (да, я виноват 👼), я стараюсь непредвзято относиться к вещам и понимать, что у меня нет ответов на все вопросы. Это определенно процесс, в котором я постоянно пытаюсь стать лучше. Спасибо еще раз!

@karelz — в настоящее время Avalonia использует OmniXaml в качестве своего механизма XAML, и, хотя он работает довольно хорошо, все еще есть ошибки и отсутствующие функции. Как и Portable.Xaml, OmniXaml поддерживается добровольцем, у которого не всегда есть много времени для работы над ним.

Если на самом деле вы решите не открывать System.Xaml, возможно, выпуск вашего тестового набора будет хорошим компромиссом — по крайней мере, таким образом мы сможем обеспечить максимальную совместимость сторонних реализаций, таких как OmniXaml и Portable.Xaml.

Я думаю, что экосистеме .net нужен формат сериализации по умолчанию, удобочитаемый для человека, что-то вроде JSON в мире Javascript. Этот формат должен использовать типы данных donet и напрямую использовать POCO в качестве схемы. Затем этот формат можно использовать для описания объектов POCO. Эти описания строго и статически типизированы. Это может быть макет пользовательского интерфейса, конфигурация приложения во время выполнения, описание проекта/рабочего процесса или даже связь между двумя программами .net. И даже связь с другими экосистемами (такими как веб/Javascript) также возможна, если они реализуют формат. Но он должен быть разработан вокруг экосистемы .net. Вот почему JSON/BOND/Protobuf/XML недостаточно.

Исторически сложилось так, что XAML частично выполнял эту обязанность. Теперь вопрос в том, насколько она хороша для этой роли. Если это достаточно хорошо, то я думаю, что XAML должен превратиться в netstandard, а затем в реализацию .net. Но, по возможности, следует учитывать и другие форматы. Кажется, на прошлой неделе вышел http://www.ammyui.com/ . Формат описания пользовательского интерфейса ориентирован на простоту, но преобразуется в XAML. Потому что XAML не был достаточно простым. Я сам предложил один формат в roslyn repodotnet/roslyn#16648, основанный на инициализаторах (объект, коллекция и индекс). И мое предложение было фактически взято (и затем слегка изменено) из этого сообщения в блоге @bricelam из команды Entity framework. И в его посте, и в моей ветке предложений есть несколько примеров.

Я хочу сказать, что для .net должен быть формат по умолчанию, будь то XAML или что-то еще.

@grokys Я действительно хотел упомянуть OmniXaml и пригласил @SuperJMN к разговору здесь, но, похоже, он никогда не хочет участвовать. Не уверен, что это настройки или что-то еще (я также сделал попытку в Gitter - поскольку вы работаете с ним, возможно, вам повезет перетащить его сюда 😄). OmniXaml, безусловно, также приветствуется в этом разговоре.

@gulshan +💯 👏 👏! Ха-ха. Часть запутанной части всего этого заключается в том, что Xaml ЯВЛЯЕТСЯ форматом и технологией MSFT. Со всеми инвестициями и инструментами, построенными вокруг него — как с MSFT, так и на предприятиях, действительно непонятно, почему существует пробел в обеспечении его непрерывности, чтобы можно было использовать существующие усилия и инвестиции.

Тем не менее, мне нравится то, что я вижу с Эмми, и я продолжаю относиться к этому непредвзято. Или попытаться иметь один. 👼

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

• Императивный языковой агностик . Использование файлов не требует знания языка программирования.
• Дружественный к дизайнеру/инструменту. _Использование визуального дизайнера и/или включение визуального дизайнера в ваш продукт приводит к снижению совокупной стоимости владения _.

Тем не менее, что лично для меня важно:

• Интегрированный рабочий процесс разработчика/дизайнера
• Опыт визуального дизайнера для ручного редактирования файлов.
  
  
  
  • PropertyGrid (окно свойств) с расширяемым API редактора, как обсуждалось выше.
  
  
• Расширения разметки
• Вишенка на торте: возможность использовать все вышеперечисленное в сценариях вне разработки (пример DevOps выше).

Если все это будет соблюдено, то я был бы готов рассмотреть «другой формат .NET», но, очевидно, я бы предпочел поддерживать и расширять Xaml как этот формат. В конце концов, это технология MSFT и, следовательно, интеллектуальная собственность.

@Mike-EEE Если формат можно десериализовать в POCO, все эти функции должны работать. Окно свойств в VS появляется и для сценариев, отличных от XAML. Но меня беспокоит читаемость без какой-либо поддержки редактора. В некоторых случаях вам нужно отредактировать файл конфигурации на удаленном сервере, и у вас есть только vim. По сравнению с JSON, XML (и XAML) не так хорош в этом отношении, ИМХО.

Но в XAML есть некоторые уникальные вещи (на самом деле не XML-функции), такие как прикрепленные свойства, которые трудно имитировать в простом формате сериализации.

Я бы сначала проголосовал за WPF (чтобы наконец-то попрощаться с xamarin.froms), а затем за xaml

Окно свойств в VS появляется и для сценариев, отличных от XAML.

Правильно, но он почти не «загорается», как для Xaml, с полностью настраиваемыми элементами управления редактированием и т. д. Поправьте меня, если я ошибаюсь. Вы не можете просто навести курсор на свойство в этих форматах и ​​получить раскрывающийся список для поля перечисления (например). Этот опыт, по сути, является следующей формой и версией WinForms, что является одной из причин, по которой он так хорош (WinForms по-прежнему популярен!).

По сравнению с JSON, XML (и XAML) не так хорош в этом отношении, ИМХО.

Да, я согласен, Xaml не совсем краток, и вы услышите жалобы на то, насколько он многословен. Именно здесь OmniXaml вносит свой вклад, предоставляя улучшения в области форматирования. Вы также конкурируете с подобными другими форматами, такими как TOML и YAML и тому подобное.

функции, отличные от XML), такие как прикрепленные свойства...

И расширения разметки. 😄 Это особенности его видения.

То, что (я полагаю) вы здесь трогаете @gulshan , по сути, является «Data AST (абстрактное синтаксическое дерево)». Если мы говорим о серьезном улучшении Xaml (или формата данных .NET), то это правильный путь. Он может питаться даже от Roslyn. На самом деле, у меня есть голос пользователя за эту самую идею (вместе с соответствующим постом в блоге ). К сожалению, это не очень популярно, так как это довольно сложно объяснить, ха-ха. По сути, у вас есть дерево AST (данных), которое можно записать в любом количестве форматов. Таким образом, разработчики (и инструменты) могут работать с ним в любом формате, который им наиболее подходит (эстетически или иным образом).

так что я наконец могу попрощаться с xamarin.froms

Согласен с вами в этом аспекте @groege. 😎

@Mike-EEE Ранее не проверял ваше предложение Data AST. Да, это концептуально похоже на предложение сериализации/обозначения объектов по умолчанию для .net. Идея трудна для понимания из-за ее абстрактности. 😄

Что касается XAML, формат сериализации строго типизированных данных на основе .net устранит потребность во многих расширениях разметки XAML. Тем не менее, останутся некоторые, которые не могут быть инициализированы каким-либо выражением (без конструкторов). Я бы хотел, чтобы некоторые из этих возможностей расширения разметки были частью самого C#.

Ну, я не получил ответа от @karelz , поэтому я могу только предположить, что с тех пор он сидел перед своим монитором как таковой, узнав, что вы можете определить консольное приложение в Xaml:

(Плохие) шутки в сторону, пожалуйста, дайте мне знать, если у вас есть дополнительные вопросы.

Кроме того, с This Week in .NET выглядит довольно крутой движок, который назревает в .NET Core . В первом комментарии этого поста все сказано . :)

@Mike-EEE Я знаю, что должен тебе ответить (он помечен как важный в моем почтовом ящике и открыт в браузере).
До сих пор я мог только просматривать ответы (большое спасибо всем за все подробности и идеи!), но у меня не было времени, чтобы изучить Xaml (как вы указываете) и внимательно прочитать все ответы, чтобы быть могу ответить... извините, сейчас слишком много пожаров и хай-приса :(, я вернусь к этому позже, обещаю!

Всем добра @karelz! Очень ценю ваши усилия и диалог здесь.

Вот голосование за WPF с открытым исходным кодом, по сравнению с ним любая другая версия XAML - мусор. А если серьезно, ребята, завершите цикл, создайте .net core/XAML STORE для Unix и MacOS.

@Mike-EEE, очень жаль, у меня все еще не было времени вернуться к этой проблеме :(

О, чувак, не беспокойся об этом, @karelz , я знаю, что все сейчас заняты. Я ценю разговор больше всего на свете. У меня многое вылетело из головы. Приятно видеть это там и размышлять об этом как таковом. Кроме того, мы уже потратили на это год+ ожидание... сколько еще месяцев или около того? :)

они должны открыть исходный код Silverlight 5 .. так как их движение html5, их перемещение win8 / winrt ... и теперь uwp & win10 и xamarin .... ОБЩЕ!! жалко, что ты потерялся в ла-ла-ленде, как в Голливуде или что-то в этом роде...

как можно перейти с silverlight 5 на всю эту хрень? КАК? как вы можете говорить, что уважаете своих пользователей, когда вы всегда ломаете интерфейсы сборки. бета-тестер, потому что ты слишком тупой, чтобы ясно мыслить, прежде чем создавать идеи и кодировать их.

вам нужно устранить необходимость в проектах ios/android/uwp в формах xamarin. ДУМАЙТЕ, что есть гораздо лучшие способы поддержки многоплатформенности, чем наличие проекта для каждой платформы.

теперь подведите все под одну ф. framework вы жопу салфетки (я рекомендую покрытие wpf/silverlight и язык xaml, но, черт возьми, если вы хотите перенести все в xamarin, но, пожалуйста, не могли бы вы добавить типы данных в стиль/шаблоны.. странное упущение, как и многие, и убедитесь, что ваш f. nucrapget работает A1 на этот раз .. какого черта мне нужно установить пакет nuget во всех зависимых сборках?то же самое с dll, на которую ссылаются ..?у вас нет видения... niet none... capout... все это время застрял в мс дерьмо .. я мог бы построить свои собственные SDK мирового класса ..

я не могу провести день без того, чтобы MS не вывалил дерьмо на мою дорогу .. я серьезно подумываю о scala-js или просто о быстром .. пора выходить из дома! я сыт по горло

Что ж, им потребовалось почти два года, но UWP наконец-то определил расширения разметки для своей модели Xaml:
https://wpdev.uservoice.com/forums/110705-универсальная-платформа-Windows/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

Также следует отметить, что Noesis запустила свой продукт v2.0 на прошлой неделе, и он выглядит довольно впечатляюще. В его системе Xaml уже есть расширения разметки (на C++, на подходе C#), и им не понадобилось семь лет, чтобы разработать спецификацию. Теперь это также бесплатно для независимых разработчиков. Как только вы учтете его поддержку AmmyUI , я должен сказать, что это первое место в моем списке, поскольку модели Xaml идут в ATM:

http://www.noesisengine.com/

Привет , @karelz , возможно, ты сможешь это прокомментировать. Но знаете ли вы, имеет ли «спецификация» UWP Xaml, которая происходит сейчас, какое-либо отношение к этой проблеме? Если нет, то знаете ли вы, может ли это быть? Сумасшедшая идея, но было бы неплохо решить две проблемы по цене одной, если можно помочь. Я также оставил там сообщение о голосовании UWP, но решил, что пропингую и здесь.

@Mike-EEE «Спецификация» UWP Xaml, вероятно, управляется другой организацией (я думаю, в Windows) — запросить у них подробности о голосе пользователя, вероятно, лучший канал.

Да, я боялся этого. 😛 Я получил там ответ, но, честно говоря, для меня это не имеет особого смысла.

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

Возможно, им втайне нравится, когда разработчики жалуются на их работу. :)

В любом случае, если вы читаете это и являетесь сторонником прозрачного сотрудничества и разработки с открытым исходным кодом, и вам понравилось быть частью успеха инициативы asp/.NET Core в этой области, пожалуйста, найдите секунду, чтобы перейти к на WPDev UserVoice и отправьте им записку с призывом сделать то же самое. Ссылка была упомянута ранее, но вот она снова для тех, кто читает это по электронной почте:
https://wpdev.uservoice.com/forums/110705-универсальная-платформа-Windows/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

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

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

Обновлять:
https://github.com/microsoft/xaml-стандарт

Я уверен, что @Mike-EEE будет очень доволен этим ;P

Это отличный ход. Спасибо, что поделились @RichiCoder1

К сожалению, это только интерфейс. Другие способы использования XAML, такие как Sharepoint и WF, вероятно, отсутствуют.

Но да, по крайней мере, это поможет стандартизировать XAML для всех поддерживаемых платформ.

Хороший ход!

Надеюсь, они разделят его на слои

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

@galvesribeiro Похоже, кто-то создал проблему: https://github.com/Microsoft/xaml-standard/issues/23 Я бы +1, нет причин, по которым возможный стандарт не будет разделен.

Я уверен, что @Mike-EEE будет очень доволен этим ;P

Ха-ха, и ты прав, @RichiCoder1! Все неправильно и сломано, и не там, где должно быть, но это начало. ;) Спасибо, что дали нам знать. 👍

И очень приятно видеть, что кто-то создает https://github.com/Microsoft/xaml-standard/issues/23, чтобы мне не пришлось. ;) ;) ;)

Пожалуйста, рассмотрите возможность включения WF (Workflow Foundation) в стандарт XAML!!.

@Suriman, пожалуйста, проголосуйте!
https://github.com/Microsoft/xaml-standard/issues/23

Так что я ненавижу спрашивать — и я делаю это в интересах быть хорошим гражданином репо/выпуска, но нужен ли этот выпуск больше? Я имею в виду, что в этом репозитории уже собрано более 50 проблем, которые раскрываются НАМНОГО подробнее, чем эта проблема. Похоже, у него уже есть своя жизнь!

Есть ли причина держать этот вопрос здесь открытым? Если я что-то совсем не понимаю (вполне возможно), я думаю, что мы достигли цели здесь с помощью стандарта Xaml. Он управляется сообществом и всем, что наиболее важно лично для меня. :)

@Mike-EEE Между этими двумя проблемами есть тонкая разница; мне кажется, что один из них касается стандартизации API-интерфейсов, доступных в самом XAML (строго в самом XAML), а другой касается поддержки XAML как стандартного компонента .NET, аналогичного System.Xaml.

@lokitoth определенно готов к разговору об этом, так как я все еще пытаюсь понять все новые вещи. Я полагаю, что лучше всего начать с предложения посмотреть отличное и информативное видео @terrajobst , которое демонстрирует код, «просто работающий» с новым .NET Standard 2.0. Лично я не задумывался о том, как это повлияет на System.Xaml. Я думал, что это должно «просто работать», но, возможно, я начинаю думать, что сейчас ошибаюсь (а-а, слишком хорошо, чтобы быть правдой).

И, честно говоря, прочитав несколько таких тем в репозитории Xaml Standard, я как бы корил себя за свое более раннее предложение (☕️ кофе заставил меня сделать это, клянусь! ☕️). Судя по всему, «Стандарт Xaml» лучше назвать «Стандарт MSFT UX/UI», поскольку именно это в первую очередь обсуждается в этом репозитории. В нынешнем виде Xaml как мощная технология сериализации вообще не представляется/не демонстрируется/не выделяется (за исключением нескольких смелых голосов здесь, которые приложили усилия), что также приводит к некоторой разобщенности/путанице.

Лично я не задумывался о том, как это повлияет на System.Xaml.

Нам потребуется проверить сборку, чтобы выяснить, можно ли загрузить ее дерево зависимостей в контексте .NET Standard 2.0. Если это чистый .NET, он, вероятно, будет работать (хотя есть целый набор элементов времени компиляции, например BAML, встроенные ресурсы и т. д., которые должны быть включены в цепочку инструментов .NET Core)

Судя по всему, «Стандарт Xaml» лучше назвать «Стандарт MSFT UX/UI», поскольку именно это в первую очередь обсуждается в этом репозитории.

Я думаю, что это больше связано с объявлением об этом в контексте UWP/Xamarin.Forms, что означает, что разработчики, сосредоточенные на этих двух платформах, которые, возможно, не имели доступа к «BigXaml», вносят основной вклад. Хотя вы видите несколько открытых проблем «принести все диалекты WPF XAML».

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

@Mike-EEE @terrajobst @terrajobst @cwensley @mellinoe
Я создал задачу в Xaml Standard.
https://github.com/Microsoft/xaml-standard/issues/57

Спасибо за внимание и участие в беседе, @juepiezhongren!

хорошо , @lokitoth , я рад, что мы сохранили эту проблему, поскольку было решено, что https://github.com/Microsoft/xaml-standard/issues/23 не подходит для дневного света.

Однако я создал новую проблему, которая, как мне кажется, лучше описывает проблему, и было бы здорово, если бы ваш голос и/или вклад были добавлены сюда: https://github.com/Microsoft/xaml-standard /вопросы/145

Чтобы уточнить, то, что вы ищете, на самом деле будет сгенерированными артефактами _JavaScript_+HTML5+CSS3. TypeScript на самом деле является транспилером для JS. Вместо создания транспилятора .NET для создания совместимого со стандартами JS, который будет эффективно выполняться при просмотре (например, JSIL ), MSFT решила потратить драгоценное время создателя C# на создание чего-то, что могло бы эффективно и в конечном итоге конкурировать с ним.

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

Кроме того, еще один момент заключается в том, что CSHTML5 очень близок к тому, что вы ищете @weitzhandler , но он не позволяет использовать общий код между сборками клиент/сервер (например, PCL и т. д.). Таким образом, вы по-прежнему получаете две отдельные несовместимые базы кода, которые необходимо поддерживать, что приводит к одной и той же проблеме затрат/бизнеса между .NET и JS (или TypeScript 😉), которой, скажем, не существует в строгом решении NodeJS.

Моя мечта - использовать стиль написания пользовательского интерфейса android xml для настольных приложений с ядром dot net! Да, действительно!!

Любые попытки портировать XAML на ядро ​​.NET я готов добровольно.

В моих модификациях CoreWf (WorkflowFoundation в сетевом стандарте 2.0) я вижу, что System.Xaml или более совместимая реализация Portable.Xaml, вероятно, потребуется, чтобы разрешить загрузку DynamicActivity из Xaml . У меня есть CoreWf, работающий на платформе .net с базовой загрузкой DynamicActivity с использованием System.Xaml, но все еще не удается из-за недопустимого состояния синтаксического анализа в ядре .net с помощью Portable.Xaml.

Один вопрос: почему код System.Xaml не добавлен в репозиторий справочных источников с лицензией MIT? Есть ли лицензионные, патентные или другие проблемы? Если нет проблем, добавление этого кода в исходный код позволит нам, сообществу, выполнить перенос, необходимый для поддержки CoreWf. Репозиторий с исходным кодом не обязывает Microsoft поддерживать System.Xaml. Должен ли я добавить туда проблему с просьбой открыть System.Xaml?

Если System.Xaml не открыт, можем ли мы получить документ (отличный от спецификации Xaml) или поддержку в виде тестов, описывающих правильные шаги по анализу и токенизации кода Xaml для WorkflowFoundation?

Привет, FWIW @karelz. Я поделился некоторыми мыслями о сценарии DevOps здесь:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

На основе некоторых интересных событий в Visual Studio Xaml Designer:
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

Думал, что упомяну об этом здесь, пока я был в этом. 👍 К тому же, этот тред давно пора поднять. 😆

@weitzhandler , вам нужно обновиться, так как mono-wasm находится на стадии альфа-тестирования, уже почти пора забыть о js.

@weitzhandler Требуется 2 или 3 года, но это не просто полный стек, это универсальный стек для .net.

CoreRT также находится на борту — https://github.com/dotnet/corert/pull/4480 . Надеюсь на готовую комбинацию HTML+CSS+C# в следующем году.

Предлагаемый пакет совместимости .net включает System.Xaml со статусом «возможно» и связан с этой проблемой.

Очевидно, эта проблема была связана с пакетом совместимости 2.1? Кто-нибудь может подтвердить? Я вижу, что он помечен как netfx-compat-pack, но без версии. Тем не менее, я возьму это на себя во всем, что произошло до сих пор. 😄

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

@Mike-EEE, кажется, должен появиться xamarin.wasm.
https://github.com/mono/mono/pull/5924#issuecomment-343551464

Спасибо за обновление господа. Ценю, что ты думаешь обо мне. :) @terrajobst , это действительно разочаровывает, но я ценю, что вы нашли время, чтобы проверить и обновить. Я не был уверен, подписаны ли вы на эту тему или нет. 👼

Поскольку мы тратим время на беззастенчивое подключение проектов (и что пройдет некоторое время, прежде чем мы получим официальное исправление Xaml), я воспользуюсь секундой, чтобы упомянуть, что я провел прошлый год, помогая с версией 2 ExtendedXmlSerializer , который был недавно выпущен. Он имеет экспериментальную поддержку расширений разметки и прикрепленных свойств (которые работают на POCO, DependencyObject не требуется), а также параметризованную сериализацию в стиле protobuf .

Если вы ищете (или хотите добавить) Xaml-функциональность, пока мы ждем прибытия System.Xaml, не стесняйтесь проверить ее, оставить отзыв или (еще лучше) отправить PR в репозиторий. 👍

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

@danmosemsft будет ли поддерживаться XAML Workflow Foundation в проектах SDK в рамках инициативы 3.0 для настольных ПК?

@lokki Я не знаю планов. @terrajobst @karelz?

@danmosemsft
Почему нет проблемы с надписью «Предоставить инфраструктуру пользовательского интерфейса как часть .NET Core»?

В этом выпуске конкретно не говорится об отсутствии фреймворка пользовательского интерфейса, и похоже, что люди здесь не понимают этого.
См. это: https://github.com/Microsoft/xaml-standard/issues/232 .

@weitzhandler Теперь эта проблема имеет для меня НАМНОГО больше смысла. Спасибо за разъяснения.

Я вижу, что включение System.Xaml в .NET Standard полезно, особенно вместе со стандартом XAML.

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

@birbilis недостаточно. Один и тот же XAML должен отображаться одинаково на всех платформах.

Инициатива настольных компьютеров заключается не в XAML, а в том, что .NET Core не является бункером с наименьшим общим знаменателем, а вместо этого позволяет приложениям, которые могут быть ориентированы на определенные платформы (или, в идеале, также динамически адаптироваться к платформе, на которой они работают) и сделать лучше всего использовать их, выполнять интеграцию с конкретной платформой и т. д. Можно создавать API-интерфейсы на основе возможностей поверх этой функциональности, чтобы затем можно было писать приложения, которые просто запрашивают доступность конкретной возможности. Кроме того, на этом можно построить API-интерфейсы абстрагирования/совместимости, подключаясь к различным реализациям для каждой платформы, в поддержке которых заинтересованы авторы API.

На данный момент, я думаю, Portable.Xaml сейчас настолько близок к System.Xaml. Если вы обнаружите какую-либо проблему, пожалуйста, дайте отзыв.

Команда WPF (@dotnet/wpf-developers) только что объявила об открытии исходного кода WPF для .NET Core 3.0. В связи с этим предварительные сборки для .NET Core 3.0 теперь содержат System.Xaml, а соответствующие источники доступны по адресу https://www.github.com/dotnet/wpf.

Кстати