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

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

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

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

2
Mikko Rantanen 2 Май 2009 в 23:37

3 ответа

Лучший ответ

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

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

2
Jarek Kardas 31 Дек 2009 в 20:29
Гм. С первого взгляда кажется, что Prism сосредоточена на совместном использовании кода на уровне исходного кода. Это требуется между WPF и Silverlight, поскольку они двоично несовместимы. В основном я имел в виду совместное использование кода на уровне сборки. Однако это было с первого взгляда. Утром нужно получше присмотреться.
 – 
Mikko Rantanen
3 Май 2009 в 03:07
Ой. И второй момент, который я отметил. Если Prism требует полного доверия, это более или менее ограничивает возможность использовать его напрямую из XBAP без предварительного развертывания? Опять быстрый взгляд. Присмотритесь утром получше!
 – 
Mikko Rantanen
3 Май 2009 в 03:09
1
На самом деле это не требует полного доверия. Основная идея состоит в том, что у вас есть два проекта Shell (один для Wpf, один для Xbap), которые обеспечивают точку входа для приложения. Все сборки с бизнес-логикой / пользовательским интерфейсом являются общими. Вы создаете интерфейсы для служб и двух различных конкретных реализаций в зависимости от контекста, в котором они работают (WCF, если Xbap, прямые вызовы, если Wpf). Во время выполнения вы используете шаблон внедрения зависимостей для предоставления надлежащих услуг вашему приложению.
 – 
Jarek Kardas
3 Май 2009 в 03:18
Мертвая ссылка :( Firefox не может найти сервер на mokosh.co.uk.
 – 
felickz
18 Янв 2012 в 23:07

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

  • Основной проект, который создает 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 и без необходимости в генерации отдельного кода или связывании в коде прокси / заглушки.

0
Ray Burns 1 Янв 2010 в 12:22

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

alt text
(источник: scorbs.com)

3
Glorfindel 22 Мар 2019 в 05:59