Здравствуйте, Athari , Вы писали:

A>Здравствуйте, ionoy, Вы писали:

I>>Оно прибито к конкретным фреймворкам, так как нужно знать основные типы вроде DependencyObject. С другой стороны, добавить поддержку новой платформы совсем не сложно. Вот, например, как была добавлена поддержка Авалонии: https://github.com/AmmyUI/AmmyUI/blob/master/src/Core/Ammy.Platforms/AvaloniaPlatform.cs

A>Если я сунусь в AmmyUI со своим CsConsoleFormat, про который никто не слышал, велик шанс, что меня не поймут.

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

A>Из AmmyUI вычленяется что-нибудь вроде System.Xaml/Newtonsoft.Json, чтобы можно было прикрутить к своей библиотеке пакет для поддержки синтаксиса? (Впрочем System.Xaml/Portable.Xaml здесь не самый лучший пример пример, так как требует добавления зависимости в основную библиотеку из-за атрибутов.)

Можно вытащить сам парсер, без AST части. Выпилить оттуда всё что тебе не нужно и прикрутить свой AST. Ну или голым парсером пользоваться.

I>>bind есть, как и все остальные встроенные синтаксические расширения. Для bind даже есть свой синтаксис, который позволяет определять конвертер по месту.

A>Binding — это часть PresentationFramework, а не System.Xaml, и в других фреймворках, полагаю, он тоже свой. Так что если это работает универсально, как вы описали, то я не понял, как это сделано.
Он везде свой, но различия небольшие.

A>Если написать свой велосипедный синтаксис, просто упрощающий XAML до Ammy-подобного вида, но без разбора C# и прочих премудростей, и с трансформацией сразу в объекты, минуя промежуточный XAML (в идеале, наверное, генерировать код C# а-ля .designer.cs из WinForms...), то:

A>1. Что я при этом теряю? (Я так понимаю, мне не светит автодополнение кода по элементам из той же сборки. Code-behind у меня и так нет, это не проблема.)
Автодополнение получить не так уж и сложно. Но придётся разбираться с Нитрой, без этого никак.

A>2. Будет ли моя библиотека Alba.CsConsoleFormat.CoolSyntaxSupport заставлять конечное приложение тащить с собой какие-нибудь дополнительные зависимости?
Конечное приложение — нет. Сам плагин — да.

A>3. Что мне придётся писать ручками? (Я так понимаю, надо будет прикручиваться к системе сборки и допиливать автодополнение кода.)
Ну да.
1) Пишешь MSBuild таск
2) Передаёшь туда свои файлы
3) Скармливаешь их Нитре
4) На основании результата работы Нитры генерируешь C# файлы

A>В общем, хотелось бы понять перспективность простого ограниченного решения — формата сериализации специально для моей библиотеки. У меня только элементы, одноразовые биндинги, ресурсы в корне и односторонние конвертеры, всё минималистично.
Зависит от того, насколько далеко ты хочешь с этим решением зайти. Если подсветка и интеллисенс не нужны, то можно обойтись XML парсером и всё сделать вручную. Там работы вроде немного должно получится. Если же хочется, чтобы всё было красиво, то придётся разобраться с Нитрой. Насколько я понимаю, плагин для студии уже работает, так что студийного кода тебе писать не придётся. Достаточно будет описать свой язык, ну и MSBuild таск, для компиляции. Хотя, если не хочется возиться, то можно генерировать результат по сохранению файла, без таска.