Application Release/Upgrade Strategyfor dla aplikacji biznesowych Silverlight?

Question

Ciekawi mnie słuch, jeśli inni zajmowali się zarządzaniem wersjami aplikacji Silverlight.

Mam aplikację biznesową, która ma zostać wkrótce wydana, a także dotyczy "wydania" aktualizacji tej aplikacji. Zazwyczaj użytkownicy tej aplikacji pozostawiają aplikację otwartą przez cały dzień (i potencjalnie całą noc) bez jej ponownego ładowania.

Co należy zrobić, jeśli trzeba wprowadzić zmianę obejmującą zmianę interfejsu usługi sieciowej? W jaki sposób można to wdrożyć bez powodowania błędów po stronie klienta?

Jesteśmy już tak przyzwyczajeni do wdrażania aplikacji ASP.Net, po prostu upuszczając najnowszy kod na serwerze. Mój jedyny pomysł obejmuje obecnie numer wersji klienta i okresowy zegar do sprawdzania aktualizacji.

Chciałbym wiedzieć, co zrobili inni przed wdrożeniem tego.

Dzięki Mike

Answer 1

po prostu odpowiedzi na pytanie, w jaki sposób, aby upewnić się, że pliki .xap nie są buforowane przez przeglądarkę, co może być pomocne:
Prevent Silverlight xap from being cached by proxy server

Ale to nie jest użyj, jeśli użytkownicy ponownie ładują aplikację. W mojej własnej aplikacji nie stanowi to problemu, ponieważ użytkownicy będą automatycznie odrzucani, gdy wdrażamy aktualizację do usługi internetowej. Ale podoba mi się twój pomysł z timerem, poszedłbym z tym.

Answer 2

Stwierdzenie oczywistości, ale nie rób niczego, aby drażnić użytkowników. Na przykład. Czy mogliby spędzić dwadzieścia minut na wprowadzaniu danych, po prostu zgubili się na ekspresie do kawy i wrócili do kliknięcia Prześlij, aby znaleźć czas, który upłynął, zauważyli aktualizację i ich praca została utracona z powodu wymuszonego restartu?

Jeśli tak, i przyznam, że to nie było zbyt wiele do myślenia, jeśli np. musisz wprowadzić zmiany w usłudze sieciowej, które łamią bieżące wydanie, czy możesz mieć nową wersję usługi sieciowej obok siebie, tak aby użytkownicy nie zostali wyrzuceni, dopóki nie upłynie czas, a jednostka pracy zostanie zakończona? Czy to również stwierdza oczywistość?

Answer 3

Dla kodu serwera, tj. Punkty końcowe robią to, jak zwykle. dla Xap myślę, że masz kilka opcji w zależności od tego, jak radzisz sobie z komunikacją. Możesz mieć żądanie zawierające numer wersji, a jeśli serwer został zaktualizowany, wymuś trochę kodu, aby przeładować klienta, trochę głupi, niechlujny, ale wykonalny. Być może czystszym rozwiązaniem byłoby kontrolowanie sesji klientów, która prawdopodobnie jest nieodłączną częścią wniosków do backedn. Po wdrożeniu nowej wersji można unieważnić sesję klienta, co może zmusić do odświeżenia strony za pomocą niestandardowej logiki. Jeśli twój protokół jest bazą typu "push", możesz wysłać komendę do klienta, aby zrobić to, co chcesz, dla wielu systemów, które są przez cały dzień prawdopodobne, że ta infrastruktura będzie istnieć (jeśli dobrze ją skompilujesz :)). Na przykład nasza warstwa usług jest oddzielona od modeli repozytoriów i modeli widoków, w naszym przypadku moglibyśmy wysłać wylogowanie lub być może specjalne polecenie, aby wprowadzić niestandardową logikę na kliencie informując, że aplikacja jest aktualizowana i odświeżyć przeglądarka po zakończeniu. Nasza powłoka ma niewielką wagę, więc nasze moduły (w zasadzie inne moduły xap) mogą być aktualizowane w czasie do odświeżenia.

Answer 4

Polecam do korzystania z rozwiązania jak wspomniano w App Arch Przewodnik:

The Guide Chapter I mean patrz rozważania wdrażania.

• podziału zgłoszenia do logicznych modułów, które mogą być buforowane oddzielnie, a które mogą być zastąpione łatwo bez konieczności użytkownikowi pobrania całej aplikacji ponownie.
• Wersja składników.

Answer 5

Czy zastanawiałeś się nad utrzymywaniem kanału o numerze WCF polling duplex, który ostrzega aplikację, gdy trzeba ją ponownie wczytać? Ponadto wywołania funkcji WCF można kierować bezpośrednio do katalogu wirtualnego zawierającego połączenia "z interfejsem". Np

aplikacji Silverlight obsługiwany w „XXXX \ Defalult.aspx” Silverlight rozmów do WCF w „\ XXXX \ Version2 DataPortal.svc” DataPortal.svc rozmowy do GAC (lub inaczej) podstawy montażowej, które można zidentyfikować jaka wersja może obsłużyć jakie połączenia.

W ten sposób, po uaktualnieniu do "x.x.x.x \ Version3 \ DataPortal.svc", nadal można wykonywać połączenia z wersją 2, zakładając, że te wywołania zawierają kod do konwersji na wersję 3.

Pomaga to w przypadkach, w których Twoja aplikacja biznesowa ma dynamiczne pobieranie xap ("główne", "klient", "zasoby reklamowe" itd.) I chcesz je zwolnić niezależnie.