Quelles sont les meilleures pratiques pour pouvoir déployer un service Windows qui devra être mis à jour?
J'ai un service Windows que je déploierai mais peut nécessiter des versions de débogage et de nouvelles versions pendant le processus bêta. Quelle est la meilleure façon de gérer cela? Idéalement, j'aimerais trouver une solution de déploiement de type ClickOnce pour les services Windows, mais ma compréhension est que cela n'existe pas. Quel est le plus proche que je puisse arriver à clickonce pour un service Windows?
5 Réponses :
Étant donné qu'un service est longuement de toute façon, l'utilisation d'un déploiement de style ClickOnce peut ne pas être viable - car ClickOnce se met à jour uniquement lorsque vous lancez l'application. Un service ne sera généralement lancé que lorsque la machine est redémarrée.
Si vous avez besoin de mise à jour automatique d'un service, votre meilleur pari peut être de la main sur le code de la main dans le service, mais je perçoive des problèmes avec presque toutes les solutions: la plupart des processus d'installation nécessiteront un niveau d'interaction utilisateur (si seulement Pour contourner UAC), je ne peux donc pas imaginer que cela conduirait une réponse qui n'implique pas d'obtenir un utilisateur connecté devant l'écran à un moment donné.
Une idée qui pourrait simplement fonctionner est le déploiement actif-répertoire (ou un équivalent similaire). Si votre service est déployé via un programme d'installation Standard MSI-Type, AD vous permet de mettre à jour la demande en silence dans le cadre de la stratégie informatique. Je suppose que vous devriez forcer le serveur à rafraîchir la stratégie publicitaire (en redémarrant ou en utilisant gpupdate à partir de la console), mais à autre que cela devrait être un déploiement de maintien.
Je suggérerais d'utiliser l'approche "Plugin" à ce sujet, c'est-à-dire à l'aide du proxy Modèle de conception .
Lors de l'utilisation de ce modèle, un thread de l'indépendance peut vérifier sur un dossier pour les mises à jour. Vous devrez utiliser ShadowCopy sur votre déploiement de votre assembly. Lorsque votre service de mise à jour de service rencontre une nouvelle version de votre service, il doit décharger l'ensemble de production actuel et charger la nouvelle version, sans arrêter le service lui-même. Encore plus! Votre service ne devrait jamais remarquer la différence s'il n'y a pas de code de rupture dans votre assemblée.
+1. Semblable à la réponse à cette question: Stackoverflow.com/Questtions/4002462/...
Je suggérerais de créer un projet de configuration normal et d'ajouter la sortie du projet de service Windows dans ce projet de configuration.
Pour plus d'informations, veuillez vous reporter à http://support.microsoft.com/kb/816169.
J'ai un système que nous utilisons au travail ici qui semble fonctionner assez bien avec les services. Notre système déployé compte environ 20-30 services à tout moment. Au travail, nous utilisons un produit appelé TOPHEFF Vous pouvez la trouver ici http://topshelf-project.com/ < / p>
Fondamentalement topshelf traite beaucoup de choses liées au service. Installation, désinstallation, etc. Tout à partir de la ligne CMD du service. L'une des fonctionnalités très utiles est la possibilité de fonctionner comme console pour le débogage. Vous construisez un service et avec une ligne CMD différente, vous pouvez l'exécuter sous forme de console pour voir la sortie du service. Nous avons ajouté une fonctionnalité personnalisée à ce logiciel qui nous permet de configurer des profils à l'avance. Fondamentalement, nos profils configurent quelques éléments comme la journalisation, les emplacements de ressources, etc. afin que nous puissions contrôler tout cela sans avoir à republier aucun code. Tout ce que nous faisons, c'est exécuter une commande comme
D: \ services \ servicename.exe core.profiles.debug ou Pour obtenir différentes configurations de journalisation.
Notre script de construction crée install.cmd et désinstaller des scripts pour chacun de nos services tout ce que nous faisons, c'est copier les fichiers sur le serveur et exécuter le script. Si nous voulons voir la sortie de débogage, nous arrêtons le service et double-cliquez sur l'EXE et nous obtenons une console pour lire toute la sortie.
Une dernière chose que la topshelf a ce que nous n'utilisons pas parce que ce n'est pas nécessaire, c'est le concept de rayonnage (il existe une documentation sur ce site Web pour cela). Cela vous permet de mettre à jour le service sans avoir à "redémarrer", mais vous devez toujours copier les fichiers manuellement, sauf si vous construisez un système automatisé pour cela.
Cependant, ma suggestion si vous avez besoin de 100% de disponibilité de service, c'est avoir un système redondant. Quelle que soit la manière dont vous configurez votre service pour les mises à jour, vous ne pouvez pas éviter l'échec du matériel causant des temps d'arrêt sans système de basculement automatisé. Si ledit système était en place, ma stratégie de mise à jour recommandée consisterait à désactiver 1 nœud, mise à jour, test, activez l'activation de l'autre nœud, mettez à jour, testez et tournez le 2e nœud sur. Vous pouvez tout savoir avec un script simple. Cela peut être un système plus compliqué que nécessaire, mais si vous ne pouvez pas passer un service hors ligne pour un redémarrage simple qui prend 5 secondes, vous avez vraiment besoin d'un système en place pour traiter des problèmes matériels car je peux garantir que cela se produira éventuellement.
D: \ services \ servicename.exe core.profiles.Production
Une solution simple que j'utilise est de simplement arrêter le service et X-Copier les fichiers de mon dossier bin dans le dossier de service.
Un fichier de commandes pour arrêter le service puis copiez les fichiers doivent être faciles à jeter ensemble.
J'aime celui-ci, rapide et facile!
Hey j'aime ça. Je fais essentiellement la même chose à la main lors du débogage.
Voir aussi Stackoverflow.com/Questtions/4002462/...