Двойное развертывание приложения WPF изначально и в виде XBAP

Question

Как создать приложение WPF, которое можно развернуть как XBAP или как собственное приложение Windows с минимальными издержками? XBAP двоично совместимы с Windows-приложениями WPF и работают поверх того же CLR (в отличие от Silverlight). Они все еще отличаются в некоторых отношениях.

С точки зрения развертывания их наибольшее различие заключается в том, что XBAP имеет элемент управления Page в качестве основного контейнера, а приложение Windows - элемент управления Window. Было бы довольно тривиально заставить приложение Windows использовать элемент управления Page, но я чувствую (не стесняйтесь не соглашаться), что использование метода навигации по страницам в приложении Windows довольно неинтуитивно.

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

Каким будет простой и понятный способ решения следующих проблем с вышеуказанными проблемами?

Требования

1. Развертывается обоими способами: как XBAP через http и как автономный исполняемый файл WPF.
2. Показывает информацию с удаленного веб-сервера, такого как flickr, или через неуправляемый API.
3. Если возможно, методы развертывания должны оставаться верными их платформам. То есть: используйте страницы в XBAP, где они имеют смысл, и диалоговые окна в приложении Windows, где они имеют смысл.

Ограничения

1. Платформа оптимизирована. Материал, требуемый XBAP, не должен влиять на клиента Windows и наоборот.
2. Параметры развертывания позволяют использовать как можно больше кода. Это помогает в тестировании и обслуживании.
3. Запуск XBAP должен быть максимально простым. Предварительные требования к сертификату могут нарушить цель XBAP.

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

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

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

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

Answer 1

В этой статье scorbs объясняется, как это сделать, и даже для этого есть шаблон приложения.

_{(источник: scorbs.com )}

Answer 2

Возможно, вы захотите взглянуть на Prism ( на codeplex ) Это помогает нацеливаться на Wpf, Xbap и Silverlight с минимальными изменениями кода (объем дополнительной работы зависит от вашего проекта).

Вот как его использовать для создания приложений Wpf и Xbap: Приложения Prism и XBap

Answer 3

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

• Основной проект, который создает DLL, содержащую бизнес-объекты, коммуникации и пользовательский интерфейс.
• Тестовый проект, содержащий как ручные, так и автоматические юнит-тесты
• Крошечный .exe проект для приложения Windows
• Крошечный .xbap проект

В основном проекте нет ни Pages, ни Windows, только UserControls и пользовательские элементы управления. Существует также класс услуг для отображения пользовательского интерфейса. Этот класс подклассов в проектах Windows и XBAP, чтобы изменить способ отображения вещей. В каждом случае подкласс устанавливается в статическом свойстве при запуске приложения. Весь остальной код просто ссылается на это статическое свойство и вызывает для него методы. Эти методы выполняют сервисы, которые отличаются между приложениями Windows и XBAP.

Например, в моем классе обслуживания есть метод «ShowDialog», который принимает FrameworkElement и отображает его в стиле диалога, либо в виде окна (для приложения Windows), либо в виде всплывающего окна на странице (для XBAP).

Использование этого метода позволило примерно 98% совместного использования кода между приложением Windows и XBAP.

Мое основное приложение также имеет определенный интерфейс клиент-сервер и атрибуты WCF, примененные к его объектам данных. Есть статическое свойство, используемое всем кодом для доступа к сервису. Это статическое свойство инициализируется (в конструкторе класса) экземпляром конкретного класса реализации, но код запуска в проекте XBAP заменяет его клиентом WCF, поэтому XBAP запускает клиент-сервер, а приложение Windows фактически делает локальным звонки. В каждом случае это один и тот же объект на стороне сервера.

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