Discussion :

[wizad]

Bonjour,
Je vous soumet un petit problème avec les services windows car à l'heure actuelle je n'arrive pas à y trouver de solution.

J'ai créer un programme contenant un service windows et fonctionnant avec quatre argument :
"monprogramme.exe" --serviceinstall
"monprogramme.exe" --servicerun
"monprogramme.exe" --servicestop
"monprogramme.exe" --serviceuninstall

Je ne pense pas avoir besoin de détailler le rôle de chaque argument.

Le soucis qui se pose est que lors de l'installation, l'imagepath (pointant vers mon programme/service) est mal construit : l'installeur rajoute systématiquement des guillemets autour de la chaine ce qui provoque une erreur quand je tente de démarrer le service :
la chaine devrait être
"C:/.../monprogramme.exe" --servicerun
ou
C:/.../monprogramme.exe --servicerun

or elle devient

""C:/.../monprogramme.exe" --servicerun"
ou
"C:/.../monprogramme.exe --servicerun"

ce qui provoque une erreur puisque le système ne trouve plus l'executable.

Voici le code incriminé :

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
        public override void Install(System.Collections.IDictionary stateSaver)
        {
            Context = new InstallContext("", new string[] { String.Format("/assemblypath=\"{0}\" --servicerun", System.Reflection.Assembly.GetExecutingAssembly().Location) });
            base.Install(stateSaver);
        }

J'ajouterais que si je modifie le chemin manuellement dans la base de registre (une fois le service installé). Il devient possible de démarrer correctement et je ne rencontre plus d'erreur.

Si quelqu'un connait une solution à ce problème qu'il me fasse un grand signe.

D'avance merci!

[Kaidan]

Je vois pas vraiment à quoi servent ces arguments.

Un service Windows n'a pas besoin de ces arguments pour fonctionner vu qu'il intègre directement les méthodes pour démarrer, se mettre en pause, s'arrêter. Ce n'est pas une application Console classique mais une classe qui dérive de ServiceBase et qui implémente OnStart, OnStop etc.

Si tout le monde utilisait ses paramètres custom pour démarrer / arrêter un service, je crois que Windows ne pourrait pas s'en sortir.

L'installateur pense ici que ton nom de fichier contient ton argument, il requote donc tout (il y a un espace entre ton nom de programme et l'argument) ce qui est logique étant donné qu'il ne s'attend pas du tout à ce que le système doive mettre un paramètre pour lancer un service.

[wizad]

Je vois pas vraiment à quoi servent ces arguments.

Un service Windows n'a pas besoin de ces arguments pour fonctionner vu qu'il intègre directement les méthodes pour démarrer, se mettre en pause, s'arrêter. Ce n'est pas une application Console classique mais une classe qui dérive de ServiceBase et qui implémente OnStart, OnStop etc.

Sauf que en l'occurence si tu n'utilise pas d'argument voici ce que doit contenir ton main :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ServicesToRun = new ServiceBase[] { new Service() };
 
            ServiceBase.Run(ServicesToRun);

=> ce qui donne l'ordre à ton service de démarrer (l'action de démarage du service n'est donc pas réellement faite par le gestionnaire de service windows).
Concernant mon programme j'ai donc fait le choix de ne pas utiliser ce morceau de code dans le main mais de l'appeler conditionellement en fonction des arguments.

N'ayant pas bien détaillé mon protocole de démarage je vais le remettre ici :

• --start : démarrre mon programme directement en console (sans utiliser le service); utilisé par défaut si aucun paramètre n'est fournit.
• --servicestart : service manager envoyant un requete de démarage au service (permet de controler le service sans passer par l'utilitaire windows : ex : utilisation de raccourci)
• --serviceinstall : enregistre le service auprès du système
• --serviceuninstall : supprime le service du système
• --servicestop : service manager envoyant un requete d'arrêt au service (même cas d'utilisation que --servicestart)
• --servicerun : démarage interne du service (utiliser uniquement par windows pour le démarage du programme)

Je reprécise que lorsque je corrige le chemin dans la base de registre, mon protocole fonctionne correctement.

Si tout le monde utilisait ses paramètres custom pour démarrer / arrêter un service, je crois que Windows ne pourrait pas s'en sortir.

L'installateur pense ici que ton nom de fichier contient ton argument, il requote donc tout (il y a un espace entre ton nom de programme et l'argument) ce qui est logique étant donné qu'il ne s'attend pas du tout à ce que le système doive mettre un paramètre pour lancer un service.

En l'occurence windows aussi utilise des paramètres de démarages pour ses propre service; ex trouvé dans ma base de registre :

%SystemRoot%\system32\svchost.exe -k netsvcs

Ce système peut par exemple aussi permettre de regrouper deux services dans le même executable. Et le gestionnaire windows ne sera absolument pas perturbé. Ou autre exemple d'avoir plusieur service pointant le même executable mais avec des arguments différent (le cas de svchost.exe justement)

Je ne vais pas le faire ici mais je pourrais citer un bon nombre de service utilisant des paramètres dans leur chaine de démarage aussi varié que msi server, avast, sql server, le débogueur distant de visual studio 2005, apache, mysql,...

Néammoins merci de t'être un peu intérréssé à ce problème

[ced600]

Sauf que en l'occurence si tu n'utilise pas d'argument voici ce que doit contenir ton main :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ServicesToRun = new ServiceBase[] { new Service() };
 
            ServiceBase.Run(ServicesToRun);

=> ce qui donne l'ordre à ton service de démarrer

Heu ton service ne démarre pas une fois installé par défaut, il faut le spécifier.

Bon essaye de mettre cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"/assemblypath=\"{0}\" --servicerun"

Dans une variable string et ensuite fait ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new string[] { String.Format(VarString, System.Reflection.Assembly.GetExecutingAssembly().Location) }