Comment attendre l'état d'un autre processus dans .NET?

Question

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

Quelle est la meilleure approche pour l'exe d'attendre sur le service pour terminer sa tâche (le service lui-même ne se terminera pas à la fin de la tâche)?

Les deux processus ont accès à la même base de données, donc ma première pensée était une simple table qui enregistre l'état du service. Une fois qu'il est signalé que c'est fait, l'exe peut arrêter d'attendre et terminer sa tâche. D'autres approches? Permettez-moi de réitérer que le service, une fois qu'il a terminé sa tâche, restera dans un état en cours d'exécution/en mémoire, de sorte que l'attente de sa sortie ne fonctionnera pas. ;-)

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

Answer 1

Vous pouvez passer un nom Semaphore au service sur la ligne de commande (ou par un autre mécanisme, comme dur de codage), puis attendre sur le service Release() il, en appelant WaitOne() dans votre exe.

Code App:

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

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 deux voies Remoting: http://www.codeproject.com/KB/IP/TwoWayRemoting.aspx

La route de la base de données serait simples, mais pas nécessairement le meilleur.

Answer 3

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

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

Vous pouvez également utiliser l'espace de noms System.Diagnostics.Processes pour interroger un processus actif particulier, et la boucle jusqu'à ce que le processus est tué.

Answer 4

Pouvez-vous modifier le code de service? Si tel est le cas, utilisez un objet événement kernel - le service peut en créer un, votre application peut attendre qu'elle soit signalée et le service peut le signaler quand il est terminé. Vous devrez donner un nom à l'événement pour qu'il soit utilisé de façon croisée, mais c'est à peu près aussi simple que possible. Le service peut même continuer à fonctionner avec le code d'événement présent, personne ne le remarquera à moins d'essayer de créer un événement avec le même nom. (ou, votre testapp pourrait créer l'événement, le service peut alors essayer de l'ouvrir, en fonction de celui qui est démarré en premier.Si il réussit, il peut effectuer son déclenchement, sinon cela fonctionne comme d'habitude). Astuce: vous voulez un événement de réinitialisation automatique qui "retourne" son état immédiatement après avoir déclenché tous les threads en attente.

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