2009-10-21 3 views
5

Мы рассматриваем возможность переноса нашего интерфейса на XBAP. , мы выбрали XBAP, несмотря на то, что знали, что у клиентов должен быть установлен .net, поскольку мы не нацеливаем массы, а скорее ИТ-специалистов в корпоративной среде, , и это способ сохранить наши инвестиции (в пользовательском интерфейсе на основе WPF в архитектуре клиент-сервер) и пользоваться веб-развертыванием. Однако нас беспокоит зрелость платформы/архитектуры и ее принятие.Вопросы использования и погашения XBAP

Вы знаете какие-либо коммерческие приложения там, используя XBAP, и есть ли у вас опыт использования? можете ли вы подробно остановиться на этом опыте?

также, как предложил @Murph, вы можете думать о сильных причинах, чтобы предпочесть щелкнуть по XBAP (или наоборот)?

+0

При взгляде на это нужно также спросить, почему XBAP над Clickonce? К сожалению, я могу сделать многое в качестве ответа в любом случае! – Murph

+0

Хороший вопрос, я должен сказать, что не знаю, что предпочтительнее, обновит мой вопрос. –

+0

ИСПРАВЛЯЙТЕ ВСЕ! Я хотел выбрать приемник для щедрости, однако StackOverflow этого не допускал (занимает слишком много времени). Я думаю, что это действительно отстой, и я написал об этом на мета-сайте, но, увы, я не могу изменить это. так что я извиняюсь перед всеми, и спасибо за помощь! –

ответ

2

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

Вы правы, что принятие XBAP действительно очень низкое. Я думаю, что это связано прежде всего с тем, что Silverlight имеет гораздо больше смысла для большинства людей, которые хотят использовать преимущества WPF/DotNet в браузере (поскольку их приложения могут быть перекрестной платформой с Silverlight).

+0

Можете ли вы подробно остановиться на первом вопросе - clickOnce? легко ли распространять обновления? (или это копия и запуск за клик?), как я сказал, наша мотивация - это, в основном, быстрое и легкое развертывание для пользователей службы поддержки, например. что касается второго пункта - опять же, мы хотели бы использовать как можно больше существующего кода, и кажется, что silverlight будет гораздо более ограничительным при использовании наших общих сборок и т. д., так как проект silverlight не может ссылаться на сборки не silverlight. –

+0

Да, это очень просто для развертывания обновлений - это основная часть ClickOnce. Таким образом, вы публикуете новую сборку своего инструмента на HTTP-сервере, на котором они установлены, и при следующем запуске автоматически будет обновляться. Вы можете контролировать, насколько жестоким оно должно быть: принудительное обновление, запрос на обновление и т. Д. –

+0

Вы совершенно правы в Silverlight в своем случае. Я только упомянул об этом как возможное объяснение низкого принятия XBAP, а не как рекомендацию по использованию этой проблемы. –

1

Я мог ошибаться, но IIRC XBAP использует ClickOnce, поскольку это базовый метод развертывания. [Не могу найти, где я это читаю, поэтому возьмите это с солью.]

Это говорит о том, что я успешно работал с приложением WPF с помощью развертывания ClickOnce. Как было сказано ранее, вы развертываете все файлы на своем веб-сервере. Когда вы публикуете обновления, вы просто копируете их на свой веб-сервер, так как клиенты запускают приложение, которое им предлагается, чтобы обновить до последней версии, вы можете потребовать обновления или разрешить их удаление.

Его очень удобный и не требует накладных расходов браузера для запуска вашего приложения.

3

Я делаю инструмент XBAP, также для внутренних корпоративных нужд. Это довольно просто для развертывания обновлений - просто обновите версию серверного приложения, и клиенты будут обновляться при следующем подключении. Таким образом, в этом аспекте он не очень отличается от ClickOnce.

Основной проблемой для нас был режим «частичного доверия», которым вы должны подчиняться. И это происходит неправильно в некоторых очень неожиданных ситуациях, например, некоторые из наших сторонних WPF потерпели неудачу, потому что они использовали растровые эффекты WPF, которые, в свою очередь, использовали шейдеры графического процессора, которые считались нарушением безопасности системой и блокировались. Я не уверен, что эта проблема решена в ClickOnce. Слухи о том, что режим доверия XBAP будет менее параноидальным в .NET 4.

В противном случае я не вижу никакой разницы. По крайней мере, разработка XBAP и автономного WPF одинакова. (Примечание: Silverlight отличается, он использует только подмножество .NET framework, которое отдельно устанавливается и доступно для нескольких платформ. XBAP требует платформы Windows и .NET Framework 3+).

+0

в частичном доверии, насколько сложно/легко использовать модальные диалоги/открывать новые окна и т. Д.? Я читал, что открытие нового окна будет отправлять всплывающие блокировки, есть ли способ, чтобы он работал из коробки без дальнейших локальных конфигураций? –

+0

В общем, вам запрещено открывать новые окна или использовать собственные диалоги (http://msdn.microsoft.com/en-us/library/aa970910.aspx). Вы можете вызвать некоторые стандартные диалоги, такие как File Open, и вы можете создавать экземпляры Popup. Не уверены, будут ли они заблокированы или нет, но вам также придется самостоятельно реализовать «модальность» (http://social.msdn.microsoft.com/forums/en-US/wpf/thread/ef66f6a7- eb9d-42f6-86ba-7fbefb72fa95 /) ... –

+0

Другой вопрос - мой клиент вызывает веб-службу с WCF, настроенным с помощью app.config. когда я играл с XBAP, я не мог найти способ его развернуть, и в любом случае app.config недоступен, так как процесс выполняется в контексте PresentationHost. у вас есть опыт работы с альтернативой app.config (особенно в контексте веб-сервисов)?(развертывать другой файл и загружать вручную? использовать жестко-кодированную конфигурацию?) –

2

Мы разрабатываем приложение, имеющее как рабочий стол, так и веб-реализацию. Поскольку функциональность практически одинакова, мы хотим использовать одно исходное решение. Приложение представляет собой инструмент управления проектами и чертежами для приложения САПР. Наиболее важной причиной его запуска в браузере является то, что приложение будет использоваться как инструмент совместной работы для обмена данными и чертежами проекта.

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

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

Преимуществами являются, конечно же, клик после установки (и обновления) и возможность позволить пользователям устанавливать приложение «где угодно» (или, конечно, вам нужно .NET и сертификат на наш случай) через веб-сайт.

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

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

2

Вот забавный факт. В .NET 4.0 они добавили возможность развертывания приложений XBAP через ClickOnce для полного доверия. Больше не требуется частичное доверие. Это должно дать вам некоторые варианты!

Смежные вопросы