2010-10-20 24 views
8

Me dispongo a crear una aplicación que mirará un directorio para cualquier archivo creado. tiempo bastante sencillo para usar un sistema de archivos vigilante. Mi pregunta se refiere a cómo utilizarla. ¿Es una práctica común usar un servicio de Windows para garantizar que la aplicación siempre se esté ejecutando?filesystemwatcher como servicio de Windows?

he estado tratando de evitar la creación de servicios de Windows si no es necesario, pero realmente no veo una alternativa para hacerlo de esta manera en esta instancia. normalmente, convertiría mi servicio a una aplicación de consola y lo programaría usando el programador de Windows, pero eso realmente no se aplica en esta situación.

¿alguien puede recomendar una mejor forma de implementar el sistema de archivos que un servicio de Windows?

gracias por cualquier idea.

EDITAR en respuesta a los comentarios de abajo, más específicamente, acabo de ver un directorio en un servidor, y cuando se crea un nuevo archivo, tengo que mover una copia de ese archivo en una directorio diferente en el mismo servidor, tal vez cambiarle el nombre en el proceso.

La frecuencia y cantidad de archivos será bastante pequeña. quizás 5-10 como máximo en un día.

+1

Quizás implemente el servicio en un lenguaje/tiempo de ejecución que acapare la memoria y ejecute solo su programa C# cuando encuentre un archivo nuevo. – CodesInChaos

+1

@CodeInChaos: no es una gran idea. La implementación de la función FSW nativa es mucho más difícil, así como la complicación involucrada en una solución de doble proceso. Pensé que ya habíamos pasado los estereotipos sobre el código administrado. –

+1

Realmente, CodeInChaos? Estoy totalmente a favor de la eficiencia, pero no estoy seguro de que su comentario sea particularmente constructivo, y ciertamente no quiero ser el tipo que desenterrará el código de alguien más tarde, donde se hizo el cambio de idiomas para diferentes partes del proyecto. (Dicho esto, supongo que todos lo hacemos a menudo ...) – Brad

Respuesta

2

Debería describir más acerca de lo que quiere hacer, pero normalmente si tiene algo que necesita ejecutarse en segundo plano y no requiere interacción directa del usuario, entonces un servicio a menudo tiene sentido.

Puede usar Remoting para conectar un front-end a su servicio según sea necesario si lo desea.

+2

Muy cierto, aunque WCF es una mejor opción que Remoting, que ha quedado en desuso en este momento. –

+0

¡Oh genial ... realmente !? Wow, he invertido mucho tiempo recientemente descubriendo Remoting y toda su basura. :-D Oh, bueno ... supongo que iré a aprender WCF ahora. – Brad

+0

WCF es bastante increíble y decentemente fácil de recoger. Puede cambiar la funcionalidad muy fácilmente con las configuraciones también – jlafay

1

Sí, utilice un servicio para este tipo de operación, pero don'tusefilesystemwatcher. Si busca los archivos en su servicio, dont use la clase Timer tampoco.

Verifique para asegurarse de que el archivo se haya completado y que ya no esté bloqueado antes de intentar moverlo.

Es trivial de sondear para cambios de archivos (la sintaxis puede estar desactivada), y elimina gran parte de la programación adicional asociada con los eventos del observador del sistema de archivos.

While True 'or your exit condition' 
Dim _files() as FileInfo = Directory.GetFiles(yourTargetDirectory) 
For Each _file as FileInfo In _files 
    If _file.LastModifiedDate < DateTime.Now.AddMinutes(1) Then 
    'move your files' 
    End If 
Next 

End While 
+0

que recomienda como alternativa al filesystemwatcher. – czuroski

+0

La única alternativa que no incluye un sondeo es 'ReadDirectoryChangesW', mucho más difícil de lograr y los mismos problemas de confiabilidad. –

+0

He tenido suerte hasta ahora con este contenedor FileSystemWatcher ... oculta varias verrugas. http://www.codeproject.com/KB/cs/EnhancedFileSysWatcher.aspx – kenny

0

El uso de un servicio de Windows para envolver FileSystemWatcher es perfectamente bien para lo que necesita.

FSW es ​​la herramienta adecuada para el trabajo (ver el código nativo para ver el sistema de archivos es correcto), y un servicio es el mecanismo adecuado para implementarlo dado que necesita operación 'siempre encendida'.

Las credenciales del servicio también serán independientes del usuario que haya iniciado sesión, lo cual puede serle útil.

+0

No podría estar más en desacuerdo sobre FSW. Se ha demostrado que no es confiable en varias situaciones. Arrancarlo y reemplazarlo con un mecanismo de sondeo (administrado, no Win32) resolvió todos los problemas. – StingyJack

3

No estoy seguro todavía de cómo funciona el vigilante de archivos, pero esto es lo que estoy pensando: el sistema de archivos activa eventos; Quiero decir, NTFS debe estar haciendo eso. Su vigilante de archivos se engancha a esos eventos. El observador de archivos probablemente suspende el hilo en el que se está ejecutando hasta que ocurre un evento y el evento de alguna manera despierta el hilo. Un hilo suspendido utiliza muy pocos ciclos de CPU (en realidad ninguno) mientras está suspendido, por lo que esperar un evento de archivo no cuesta nada. Así que un enfoque encuestado desperdicia mucho beaucoup (eso es francés, significa 'una carga de mierda') de ciclos de CPU, pero el observador de archivos no lo hace. Probablemente pueda mirar PerfMon para ver si esto es cierto.

Cuestiones relacionadas