Стратегия выпуска / обновления приложения для бизнес-приложения Silverlight? - PullRequest
8 голосов
/ 29 января 2010

Мне интересно узнать, обращались ли другие к управлению выпуском для приложений Silverlight.

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

Что если необходимо отменить изменение, которое включает изменение интерфейса веб-службы? Как это можно развернуть без ошибок на стороне клиента?

Мы настолько привыкли к развертыванию приложений ASP.Net, просто удалив последнюю версию кода на сервере. Моя единственная идея в настоящее время включает в себя номер версии клиента и периодический таймер для проверки обновлений.

Я хотел бы знать, что другие сделали, прежде чем это реализовать.

Спасибо, Mike

Ответы [ 5 ]

1 голос
/ 29 января 2010

Я только что ответил на вопрос о том, как убедиться, что .xap файлы не кэшируются браузером, что может помочь:
Запрет кэширования Silverlight от кэширования прокси-сервером

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

0 голосов
/ 03 февраля 2010

Рассматривали ли вы работу канала WCF дуплекс , который оповещает приложение о необходимости перезагрузки? Кроме того, ваши WCF-вызовы могут быть направлены непосредственно в виртуальный каталог, содержащий «сопряженные» вызовы. Например:

Приложение Silverlight, размещенное по адресу "x.x.x.x \ Default.aspx" Silverlight общается с WCF по адресу «x.x.x.x \ Version2 \ DataPortal.svc» DataPortal.svc общается с GAC (или другой базовой) сборкой, которая может определить, какая версия может обрабатывать какие вызовы.

Таким образом, если вы обновитесь до «x.x.x.x \ Version3 \ DataPortal.svc», вы все равно сможете делать вызовы для Version2, предполагая, что эти вызовы содержат код для преобразования их в концепцию Version3.

Это помогает в тех случаях, когда в вашем бизнес-приложении динамически загружается xap («основной», «клиент», «инвентарь» и т. Д.), И вы хотите выпускать их независимо.

0 голосов
/ 03 февраля 2010

Я бы порекомендовал вам использовать решение, упомянутое в Руководстве по App Arch:

Руководство, которое я имею в виду см. Вопросы развертывания.

  • Разделите приложение на логическое модули, которые можно кэшировать отдельно, и это можно заменить легко, не требуя от пользователя скачать все приложение снова.
  • Версия ваших компонентов.
0 голосов
/ 03 февраля 2010

Для серверного кода, то есть конечные точки работают как обычно. Я думаю, у вас есть несколько вариантов в зависимости от того, как вы обрабатываете сообщения. У вас может быть запрос, содержащий номер версии, и если сервер был обновлен, то вынудите некоторый код перезагрузить клиент, немного неубедительно, грязно, но выполнимо. Возможно, более чистым решением было бы управление сеансом клиентов, который, по-видимому, является неотъемлемой частью запросов к серверу. При развертывании новой версии вы можете сделать недействительным сеанс клиента, возможно, принудительно обновив страницу с помощью пользовательской логики. Если ваш протокол является push-базой, вы можете отправить клиенту команду сделать то, что вы когда-либо захотите, для многих систем, которые работают весь день, вполне вероятно, что эта инфраструктура будет существовать (если вы хорошо ее построили :)). Например, наш сервисный уровень абстрагирован от моделей репозиториев и моделей просмотра, в нашем случае мы могли бы отправить выход из системы или, возможно, специальную команду, чтобы активировать пользовательскую логику, сообщающую об обновлении приложения и обновлении браузер, когда закончите. Наша оболочка имеет малый вес, поэтому наши модули (в основном другие xap) могут быть обновлены вовремя для обновления.

0 голосов
/ 30 января 2010

Излагая очевидное, но не делайте ничего, чтобы раздражать ваших пользователей. Например. Могут ли они потратить двадцать минут на ввод данных, отключить кофемашину и вернуться, нажав «Отправить», чтобы узнать, истек ли таймер, замечено ли обновление, и их работа потеряна из-за принудительного перезапуска?

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

...