que utilizo TextWriterTraceListener (System.Diagnostics) en mi solicitud para rastrear varias cosas como excepciones, ...TextWriterTraceListener y trazas de nombres de archivo con GUID
la aplicación se ejecuta en un servidor terminal y si hay muchos usuarios que lo utilizan simultáneamente el oyente comienza a crear muchos archivos de seguimiento con GUÍTULOS en el nombre de archivo.
¿Hay posibilidades o soluciones para evitar este comportamiento?
que acaba de tomar un vistazo a la documentación de TextWriterTraceListener y hay una nota sobre un tercio del camino hacia abajo la página
Si se hace un intento de escribir en un archivo que está en uso o no disponible, el nombre de archivo se antepone automáticamente a un GUID
Por lo tanto, esto parece ser por diseño. Si el archivo no está disponible, entonces no hay nada que se pueda hacer al respecto con la implementación actual. Lo que podría intentar es escribir una implementación personalizada de TextWriterTraceListener que anule los métodos relevantes de Write/WriteLine para que la salida vaya a un archivo, por usuario, con un nombre que mejor se adapte a sus necesidades.
Si lo que desea es que TODOS los inicios de sesión de TODOS los usuarios en el Servidor de Terminal Server vayan a un único archivo, casi seguramente necesitará ejecutar algún tipo de proceso de "tercero" que sea "propietario" del archivo y sincroniza escrituras, como un servicio de Windows que luego es llamado por su TextWriterTraceListener personalizado
Esto no explica la situación en la que me encuentro, con un grupo de aplicaciones único, ejecutando un proceso de trabajo único, escribiendo en un archivo especificado name y * still * spamming múltiples archivos de registro duplicados guid-named. No puede haber otros procesos que intenten acceder a ese archivo porque solo uno está configurado para usarlo. –
@TomW - Estoy en la misma situación. Creo que las peticiones paralelas procesadas por IIS son las culpables. Tal vez si hay un archivo de registro por subproceso, se comportaría mejor. –