Comment attendre le statut d'un autre processus dans .NET?

Question

Je travaille sur un projet de test d'intégration dans .NET. L’exécutable de la structure de test démarre un service et doit ensuite attendre que le service termine une opération.

Quelle est la meilleure approche pour que l'exe attende que le service termine sa tâche (le service lui-même ne se fermera pas à la fin de la tâche)?

Les deux processus ont accès à la même base de données. Je pensais donc tout d'abord à un tableau simple qui enregistre le statut du service. Une fois que cela est signalé, l'exe peut cesser d'attendre et achever sa tâche. Autres approches?

Permettez-moi de rappeler que le service, une fois sa tâche terminée, restera dans un état en cours d'exécution / en mémoire. Par conséquent, attendre qu'il se ferme ne fonctionnera pas. ; -)

De plus, ceci est uniquement à des fins de test d'intégration et n'entrera jamais en production, donc "simple". est le mot clé.

Answer 1

Vous pouvez transmettre un nom Semaphore au service sur la ligne de commande (ou via un autre mécanisme, comme coder en dur ), puis attendre que le service < code> Relâchez () en appelant WaitOne () dans votre fichier exe.

Code de l'application:

Semaphore s = new Semaphore(1, 1, "MyNamedSemaphore");
// start service, passing the string "MyNamedSemaphore"
s.WaitOne(); // will wait for Release() in service

Code de service:

// perform the initial task
// find semaphore name (i.e. from Environment.CommandLine)
Semaphore s = new Semaphore(1, 1, semaphoreName); // will use existing kernel object
s.Release(); // WaitOne in exe will complete

Answer 2

Les appels WMI devraient vous donner ce dont vous avez besoin. Vous pouvez capturer les événements commencés / finis et faire ce que vous devez à partir de là. (Merci à Chris Lively de me l'avoir montré)

http://weblogs.asp.net/whaggard/archive/2006/02/11/438006 .aspx

Sinon, vous pouvez utiliser l'espace de noms System.Diagnostics.Processes pour interroger un processus actif particulier et effectuer une boucle jusqu'à ce que le processus soit tué.

Answer 3

Pouvez-vous modifier le code de service?

Si tel est le cas, utilisez un objet Event du noyau: le service peut en créer un, votre application peut attendre qu'il soit signalé et le service peut le signaler dès qu'elle est terminée. Vous devrez attribuer un nom à l'événement pour qu'il puisse être utilisé dans plusieurs processus, mais c'est aussi simple que cela. Le service peut même continuer à s'exécuter avec le code d'événement présent. Personne ne le remarquera à moins d'essayer de créer un événement du même nom. (ou, votre testapp peut créer l'événement, le service peut alors essayer de l'ouvrir, en fonction de celui qui est démarré en premier. S'il réussit, il peut déclencher son déclenchement, sinon il fonctionne normalement.)

.

Conseil: vous voulez un événement à réinitialisation automatique qui «retourne» immédiatement son état et déclenche tous les threads en attente.

Je ne suis pas sûr des routines .NET, mais vous souhaitez utiliser Win32 CreateEvent, SetEvent et WaitForSingleObject.

Answer 4

Vous pouvez utiliser les canaux IPC: https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6143016.html

Ou peut-être une communication bidirectionnelle: http://www.codeproject.com/KB /IP/TwoWayRemoting.aspx

L'itinéraire de la base de données serait simple , mais pas nécessairement le meilleur.