Унифицированный XAML для WPF и Silverlight с использованием T4?

Question

Я пишу код, который используется как в WPF, так и в Silverlight. В C# я могу использовать "#if SILVERLIGHT" для условной компиляции, и он работает.

В XAML, однако, я должен использовать совершенно разные файлы XAML, так как некоторые атрибуты просто несовместимы. Файлы XAML на 99% похожи, а синхронизация - это хлопот.

Я хотел бы, чтобы преобразовать их в шаблон Т4, так что я могу сделать что-то вроде:

<SomeControl <#=ClipsToBounds()#> /> 

Где ClipsToBounds() производит разный текст для WPF и Silverlight. Требования:

• Intellisense при работе на шаблоны XAML
• сгенерированных во время сборки
• Проект должен быть самодостаточными и работа на фондовом версии Visual Studio: устанавливает различных SDKs и 3-редакторов партии не являются приемлемым
• Результаты запуска шаблона НЕ должны находиться в контроле источника. -

я обнаружил, что я могу изменить custom tool на файл XAML из MSBuild:Compile to TextTemplatingFileGenerator и я не теряю Intellisense. Однако полученные шаблоны генерируются во время разработки. Чтобы потом сгенерировать во время сборки, кажется большой болью.

У кого-нибудь есть опыт работы с подобными настройками?

Answer 1

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

Answer 2

Поскольку никто, кажется, не предложил шаблонное решение по желанию, я поделюсь опытом работы с проектами, нацеленными на SL/WPF. Многие люди будут предлагать использовать два совершенно разных файла XAML, другое представление для каждой платформы и во многом это «пуристская» вещь. Но если вы хотите устранить дублирование и уменьшить риск того, что ваши 2 цели дрейфуют друг от друга, я бы предположил, что обмен файлами XAML (с простыми ссылками на проекты) может работать приемлемо.

Есть несколько общих Несовместимость: существуют

• управления в обеих платформах в разных пространствах имен - подкласс свою собственную версию и обратитесь к этому.
• Стили и т. Д. Должны различаться между платформами - включают общий словарь ресурсов, разный для каждой платформы и ссылку по ключу.
• Элементы управления существенно отличаются или присутствуют только на одной платформе - вводят собственный контроль оболочки (что может потребовать существенной реализации в случае «отсутствует»).
• Отсутствуют основные свойства или функциональность - часто можно взломать что-то с приложенным поведением (например, ваш пример ClipsToBounds найден here).