Plusieurs instances de même application en tant que service Windows?

Question

J'ai une application qui gère le traitement lourd pour mon projet, et besoin de le convertir en un «service Windows». Je dois permettre l'exécution de plusieurs versions instances du traitement de l'application, ce qui semble être une exigence assez normale.

Je peux voir au moins trois approches pour ce faire:

1. Créez un répertoire unique installé (EXE, DLL, configuration), mais installer comme plusieurs services cas de celui-ci.
2. Avoir un seul Services instance engendrer plusieurs instances de lui-même après le lancement, un Apache.
3. Avoir un seul Services instance engendrer plusieurs threads qui fonctionnent dans le même espace de processus.

Mon intention était approche # 1, mais je continuais de trébucher sur les limites, à la fois dans la conception et surtout la documentation pour services:

• sont des paramètres jamais passés à OnStart() par les mécanismes de services normaux sur un système sans surveillance? Si oui, quand/pourquoi?
• Passer les paramètres d'exécution via le registre ImageKey semble un jeu d'enfant, existe-t-il un meilleur mécanisme?
• J'ai obtenu l'application pour installer/désinstaller lui-même comme une paire de services ("XYZ # 1", "XYZ # 2", ...), en utilisant le ImageKey pour lui remettre un numéro d'instance de paramètre de ligne de commande ("-x 1", "-x 2") mais il me manquait quelque chose. Lorsque vous tentez de démarrer le service, il échouerait avec "Le programme exécutable que ce service est configuré pour fonctionner en ne met pas en oeuvre le service

Ainsi, les questions suivantes:.

1. est-il une description concise de ce qui se passe lorsqu'un service démarre, en particulier pour les situations où le NomService n'est pas codé en dur (voir Q ci-dessus).
2. a-t-approche utilisée quelqu'un # 1? Tous les commentaires avec succès?

NOTE: J'ai déjoué le problème en utilisant l'approche # 3, donc je ne peux pas justifier beaucoup de temps à comprendre cela. Mais je pensais que quelqu'un pourrait avoir des informations sur la façon de mettre en œuvre # 1 - ou de bonnes raisons pour lesquelles ce n'est pas une bonne idée.

[Modifier] J'ai eu à l'origine une 4ème option de (installer plusieurs copies de l'application sur le disque dur), mais je l'ai enlevé parce qu'il se sent juste, euh, hackish. C'est pourquoi j'ai dit "au moins trois approches".

Toutefois, sauf si l'application est recompilée, elle doit définir dynamiquement son ServiceName, d'où la solution au troisième problème ci-dessus.Donc, à moins qu'une instance nécessaire pour modifier ses fichiers d'installation, # 1 devrait fonctionner correctement avec N fichiers de configuration dans le répertoire et une entrée de registre indiquant ce que l'instance devrait utiliser.

Answer 1

Bien que je ne puisse pas répondre à vos questions spécifiques à l'option n ° 1, je peux vous dire que l'option n ° 2 a très bien fonctionné pour nous. Nous voulions créer un domaine d'application pour chaque service 'enfant' à exécuter et pour chacun d'entre eux utiliser un fichier de configuration différent. Dans le fichier de configuration de notre service, nous avons stocké les domaines de l'application à démarrer et le fichier de configuration à utiliser. Donc, pour chaque entrée, nous avons simplement créé le domaine de l'application, définir le fichier de configuration, etc et nous sommes allés. Cette séparation de la configuration nous a permis de spécifier facilement les ports et les emplacements des fichiers journaux de manière unique pour chaque instance. Notre avantage supplémentaire est que nous avons écrit notre «service enfant» en tant qu'exe de ligne de commande et que nous avons simplement appelé ExecuteAssembly() d'AppDomain sur un nouveau thread pour chaque service «enfant». Le seul «clunk» de la solution était l'arrêt, nous n'avons pas pris la peine de créer une «bonne» solution pour cela.

Mise à jour février 2012

Il y a quelque temps nous avons commencé à utiliser les services 'nommés' (comme SQL Server). J'ai détaillé l'ensemble du processus sur mon blog dans une série "Construction d'un service Windows - Part 1 à Part 7". Ils vous emmènent à travers la création d'un hybride de ligne de commande/service Windows complet avec auto-installation. Les objectifs suivants où remplies:

• Construire un service qui peut également être utilisé à partir de la console
• enregistrement des événements appropriés de démarrage/arrêt de service et d'autres activités
• Permettant plusieurs instances en utilisant des arguments de ligne de commande
• auto installation de service et le journal des événements
• la journalisation des événements appropriée des exceptions de service et les erreurs
• Contrôle de démarrage, d'arrêt et de redémarrage des options
• Gestion des commandes de service personnalisées, le pouvoir et les événements de session
• Personnalisation service de sécurité et de contrôle d'accès

Un modèle de projet Visual complet Studio est disponible dans le dernier article de la série Building a Windows Service – Part 7: Finishing touches.

Answer 2

Check this out: Multiple Instance .NET Windows Service

Answer 3

Il y a l'option # 4 que j'utilise avec succès dans mon projet alias "instances nommées".

Chaque installation de votre application a un nom personnalisé et chaque installation a son propre service. Ils sont complètement indépendants et isolés les uns des autres. MS SQL Server utilise ce modèle si vous essayez de l'installer plusieurs fois sur une seule machine.