Je suis intéressant dans l'audition si d'autres ont traité la gestion de la libération des applications Silverlight.
J'ai une demande d'entreprise qui doit être publiée sous peu d'andam préoccupé par la mise à jour de "publication" de cette application. Typiquement, les utilisateurs de cette application laisseront l'application ouverte toute la journée (et potentiellement toute la nuit) sans le recharger.
Et si il est nécessaire de publier un changement incluant une modification d'une interface de service Web? Comment cela peut-il être déployé sans faire des erreurs sur le côté du client?
Nous avons grandi tellement utilisé pour déployer des applications ASP.NET en supprimant simplement le dernier code sur le serveur. Ma seule idée implique actuellement un numéro de version client et une minuterie périodique pour rechercher des mises à jour.
J'aimerais savoir ce que les autres ont fait avant de la mettre en œuvre.
merci, Mike
5 Réponses :
Je viens de répondre à une question sur la manière de vous assurer que les fichiers .xap ne sont pas mis en cache par le navigateur, ce qui pourrait être de l'aide: mais ce n'est pas utile si les utilisateurs jamais rechargent votre application. Dans ma propre application, ce n'est pas un problème car les utilisateurs seront automatiquement jetés chaque fois que nous déployons une mise à jour du service Web. Mais j'aime votre idée avec la minuterie, j'irais avec ça.
Empêcher Silverlight Xap d'être mis en cache par le serveur proxy < / a>
indiquant l'évidence mais ne fais rien pour ennuyer vos utilisateurs. Par exemple. Pourraient-ils passer de vingt minutes à entrer des données, nier à la machine à café et retourner à cliquer sur Soumettre pour trouver la minuterie a expiré, remarquée une mise à jour et leur travail est perdu en raison d'un redémarrage forcé?
Si oui, et j'avoue que cela n'a pas eu beaucoup de pensée, si par ex. Vous devez modifier le service Web qui brise la version actuelle, pourriez-vous avoir la nouvelle version du service Web côte à côte de telle sorte que les utilisateurs ne soient pas projetés tant que la minuterie ait expiré et que l'unité de travail est terminée? Ou est-ce que cela indique également l'évidence?
Très vrai. La «méthode de la minuterie» ne serait sécurisée que si les versions ont été déployées après des heures. Il ne serait utilisé que pendant la journée s'il y avait une libération d'urgence.
Dans ce cas particulier où les utilisateurs restent connectés pendant de longues périodes, il serait peut-être une bonne idée de sauver automatiquement leur travail à un stockage isolé à certains intervalles? Ensuite, si la minuterie expire et que l'application doit être rechargée, les éléments sauvegardés automatiques pourraient facilement être rechargés lorsque l'application est redémarrée.
pour le code serveur, c'est-à-dire les points finaux juste faire selon la normale. Pour les XAP, je pense que vous avez quelques options en fonction de la façon dont vous gérez les communications. Vous pourriez avoir une demande contenir un numéro de version et si le serveur a été mis à jour, forcer le code pour recharger le client, le bit boit, en désordre mais en mesure. Peut-être qu'une solution plus propre serait de contrôler la session des clients, qui fait probablement partie intégrante et colis avec des demandes à la lettre. Lorsque vous déployez une nouvelle version, vous pouvez invalider la session cliente, forçant peut-être une actualisation de la page avec une logique personnalisée. Si votre protocole est une base de poussée, vous pouvez envoyer une commande au client pour faire ce que vous voulez, pour de nombreux systèmes qui sont tous de la journée, il est probable que cette infrastructure existerait (si vous le construisiez bien :)). Par exemple, notre couche de service est abstraite à l'écart des modèles de dépôt et afficher des modèles, dans notre cas, nous pourrions envoyer une déconnexion ou peut-être une commande spécifique pour lancer une logique personnalisée sur le client informant l'application est en cours de mise à jour et pour rafraîchir votre navigateur lorsque vous avez terminé. Notre coquille est un poids léger afin que nos modules (fondamentalement d'autres xaps) puissent être mis à jour à temps pour l'actualisation.
Je vous recommanderais d'utiliser une solution comme mentionné dans App Arch Guide:
Le chapitre Guide Je veux dire Voir Considérations de déploiement.
Avez-vous envisagé de garder un Duplex de l'interrogation de la WCF canal qui alerte l'application lorsqu'il doit recharger? De plus, vous pouvez avoir vos appels WCF directement sur un répertoire virtuel contenant des appels «interfacés». Par exemple:
Silverlight app hébergé à "x.x.x.x \ par défaut.aspx" Silverlight parle à WCF à "x.x.x.x \ version2 \ dataportal.svc" DataPortal.SVC parle à un assemblage GAC (ou autrement de base) qui peut identifier la version peut gérer quels appels.
De cette façon, si vous passez à la mise à niveau vers "x.x.x.x \ version3 \ dataportal.svc", vous pouvez toujours effectuer des appels contre la version2, en supposant que ces appels disposent de code pour les convertir en version3.
Cela aide dans les cas où votre ligne d'application de la ligne de téléchargement XAP dynamique («Main», «client», «Inventaire», etc.) et vous souhaitez les libérer de manière indépendante.
+1 convenu. Je suppose que cela devient également un problème encore plus important dans les applications hors ligne hors de navigation.