Pregunta

Estoy trabajando en un proyecto de pruebas de integración en .NET. El ejecutable del marco de prueba inicia un servicio y luego debe esperar a que el servicio complete una operación.

¿Cuál es el mejor método para que el ejecutivo espere que el servicio complete su tarea (el servicio en sí no se cerrará al finalizar la tarea)?

Ambos procesos tienen acceso a la misma base de datos, por lo que mi primer pensamiento fue una tabla simple que registra el estado del servicio. Una vez que se indica que está hecho, el exe puede dejar de esperar y completar su tarea. ¿Otros enfoques?

Permítame reiterar que el servicio, una vez que haya completado su tarea, permanecerá en un estado de ejecución / en memoria, por lo que no funcionará esperar a que salga. ;-)

Además, esto es solo para fines de pruebas de integración, y nunca entrará en producción, así que "simple" es la palabra operativa.

¿Fue útil?

Solución

Puede pasar un nombre Semaphore al servicio en la línea de comando (o mediante algún otro mecanismo, como hard coding ), y luego esperar el servicio a < code> Release () it, llamando a WaitOne () en su exe.

Código de la aplicación:

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

Código de servicio:

// 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

Otros consejos

Las llamadas WMI deberían darle lo que necesita. Puede atrapar eventos iniciados / terminados y hacer lo que necesita desde allí. (Gracias a Chris Lively por mostrarme esto)

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

Alternativamente, puede usar System.Diagnostics.Processes namespace para consultar un proceso activo en particular y hacer un bucle hasta que el proceso finalice.

¿Puedes modificar el código de servicio?

Si es así, use un objeto de evento kernel: el servicio puede crear uno, su aplicación puede esperar a que se señale y el servicio puede señalarlo cuando haya terminado. Tendrá que darle un nombre al evento para que se use en el proceso cruzado, pero eso es lo más simple posible. El servicio incluso puede continuar ejecutándose con el código de evento presente, nadie lo notará a menos que intente crear un evento con el mismo nombre. (o, su testapp podría crear el evento, el servicio puede intentar abrirlo, dependiendo de cuál se inicie primero. Si tiene éxito, puede realizar su activación, de lo contrario funciona como de costumbre).

Sugerencia: desea un evento de reinicio automático que 'voltee' su estado inmediatamente y que active todos los hilos en espera.

No estoy seguro de las rutinas .NET, pero desea Win32 CreateEvent, SetEvent y WaitForSingleObject.

Puede usar canales IPC: https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6143016.html

O quizás comunicación remota bidireccional: http://www.codeproject.com/KB /IP/TwoWayRemoting.aspx

La ruta de la base de datos sería simple , pero no necesariamente la mejor.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top