Déploiement C# ClickOnce pour les services Windows?

Question

Quelles sont les meilleures pratiques pour pouvoir déployer un service Windows qui devra être mis à jour?

J'ai un service Windows que je vais déployer mais qui pourrait nécessiter un 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 je crois comprendre que cela n'existe pas. Quel est le plus proche de ClickOnce pour un service Windows?

Answer 1

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 copier les fichiers devrait être facile à lancer ensemble.

Net stop myService 
xcopy \\myServerWithFiles\*.* c:\WhereverTheServiceFilesAre 
net start myService 

Answer 2

Étant donné qu'un service est de longue durée malgré tout, l'utilisation du déploiement de style ClickOnce peut ne pas être viable, car ClickOnce n'est mis à jour que lorsque vous lancez l'application. Un service ne sera généralement lancé que lorsque la machine sera redémarrée. Si vous avez besoin d'une mise à jour automatique d'un service, le mieux serait de coder manuellement quelque chose dans le service, mais je prévois des problèmes avec presque toutes les solutions: la plupart des processus d'installation nécessitent un certain niveau d'interaction. seulement pour contourner UAC), donc je ne peux pas imaginer que cela conduirait à une réponse qui n'implique pas d'obtenir un utilisateur connecté en face de l'écran à un moment donné.

Une idée qui pourrait fonctionner est le déploiement de répertoire actif (ou un équivalent similaire). Si votre service est déployé via un programme d'installation de type MSI standard, AD vous permet de mettre à jour l'application en mode silencieux dans le cadre de la stratégie de l'ordinateur. Je suppose que vous devrez forcer le serveur à actualiser la stratégie AD (en redémarrant ou en utilisant gpupdate à partir de la console), mais à part cela, il devrait s'agir d'un déploiement sans intervention.

Answer 3

Je suggère d'utiliser l'approche "plugin" sur ceci, c'est-à-dire en utilisant le Proxy Design Pattern.

En utilisant ce modèle, un fil indépendant peut vérifier sur un dossier pour les mises à jour. Vous devrez utiliser ShadowCopy au cours de votre déploiement d'assembly. Lorsque votre thread de mise à jour de service rencontre une nouvelle version de votre service, il doit décharger l'assembly 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 assemblage.

Answer 4

Je suggère de créer un projet d'installation normal et d'ajouter la sortie du projet de service Windows dans ce projet d'installation.

Pour plus d'informations, veuillez vous référer au http://support.microsoft.com/kb/816169.

Answer 5

J'ai un système que nous utilisons ici qui semble fonctionner plutôt bien avec les services. Notre système déployé compte environ 20 à 30 services à tout moment. Au travail, nous utilisons un produit appelé TopShelf que vous pouvez trouver ici http://topshelf-project.com/

Fondamentalement TopShelf gère beaucoup de choses liées au service. Installation, désinstallation etc tout de la ligne cmd du service. L'une des fonctionnalités les plus utiles est la possibilité de fonctionner en tant que console pour le débogage. Vous créez un service et, avec une ligne de commande cmd différente, vous pouvez l'exécuter en tant que console pour voir la sortie du service. Nous avons ajouté une fonctionnalité personnalisée à ce logiciel qui nous permet de configurer les profils à l'avance. Fondamentalement, nos profils configurent quelques choses comme la journalisation, l'emplacement des ressources, etc. afin que nous puissions contrôler tout cela sans avoir à republier de code. Tout ce que nous faisons est de lancer une commande comme

D: \ Services \ ServiceName.exe Core.Profiles.Debug ou
D: \ Services \ ServiceName.exe Core.Profiles.Production

pour obtenir différentes configurations de journalisation. Notre script de construction crée les scripts install.cmd et uninstall.cmd pour chacun de nos services. Tout ce que nous faisons est de copier les fichiers sur le serveur et d'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 chose de plus qui a topshelf que nous n'utilisons pas parce que ce n'est pas nécessaire est le concept de rayonnage (il y a de la documentation sur ce site 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 la disponibilité de service de 100% est d'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 les défaillances matérielles provoquant des temps d'arrêt sans un système de basculement automatique. Si le système en question était en place, ma stratégie de mise à jour recommandée consisterait à éteindre 1 nœud, à mettre à jour, à tester, à éteindre l'autre nœud, à mettre à jour, à tester et à rallumer le 2e nœud. Vous pouvez le faire bien sûr avec un script simple. Cela peut être un système plus compliqué que ce dont vous avez besoin, mais si vous ne pouvez pas prendre un service hors connexion pour un redémarrage simple qui prend 5 secondes, vous avez vraiment besoin d'un système pour résoudre les problèmes matériels.