permissions - nametagedit - ¿Dónde están las mejores ubicaciones para escribir un registro de errores en Windows?
nametagedit configurado (10)
Los archivos de texto son geniales para una aplicación de servidor (dijiste Windows 2003). Debe tener un archivo de registro separado para cada aplicación de servidor, la ubicación es realmente una cuestión de convención para acordar con los administradores. Por ejemplo, para las aplicaciones ASP.NET, a menudo las he visto ubicadas en un disco separado de la aplicación bajo una estructura de carpetas que imita la estructura del directorio virtual.
Para las aplicaciones cliente, una desventaja de los archivos de texto es que un usuario puede iniciar varias copias de su aplicación (a menos que haya tomado medidas específicas para evitarlo). De modo que tiene el problema de contención si varias instancias intentan escribir en el mismo archivo de registro. Por este motivo, siempre preferiría el registro de eventos de Windows para aplicaciones cliente. Una advertencia es que debe ser un administrador para crear un registro de eventos; esto se puede hacer, por ejemplo, mediante el paquete de instalación.
Si usas un archivo, te sugiero usar la carpeta Environment.SpecialFolder. Local ApplicationData en lugar de SpecialFolder.ApplicationData según lo sugerido por otros. LocalApplicationData está en el disco local: no desea que los problemas de red le impidan iniciar sesión cuando el usuario tiene un perfil itinerante. Para una aplicación WinForms, use Application.LocalUserAppDataPath.
En cualquier caso, usaría un archivo de configuración para decidir dónde registrarme, para que pueda cambiarlo fácilmente. Por ejemplo, si usa Log4Net o un marco similar, puede configurar fácilmente si desea iniciar sesión en un archivo de texto, registro de eventos, ambos o en cualquier otro lugar (por ejemplo, una base de datos) sin cambiar su aplicación.
¿Dónde escribirías un archivo de registro de errores, digamos ErrorLog.txt , en Windows? Tenga en cuenta que la ruta debería estar abierta a usuarios básicos para permisos de escritura de archivos.
Sé que el registro de eventos es una ubicación posible para escribir errores, pero ¿funciona para los permisos de nivel de "usuario"?
EDITAR: Me estoy enfocando en Windows 2003, pero planteaba la pregunta de tal manera que tenía una "Guía general" para dónde escribir los registros de errores.
En cuanto a EventLog, he tenido problemas anteriormente en una aplicación ASP.NET donde quería iniciar sesión en el registro de eventos de Windows, pero tuve problemas de seguridad que me causaron dolor de corazón. (No recuerdo los problemas que tuve, pero recuerdo tenerlos).
% TEMP% siempre es una buena ubicación para los registros que encuentro.
Ir contra la corriente aquí - depende de lo que necesita hacer. A veces es necesario manipular los resultados, por lo que log.txt es el camino a seguir. Es simple, mutable y fácil de buscar.
Tome un ejemplo de Joel. Fogbugz enviará un registro / volcado de mensajes de error a través de http a su servidor. Podría hacer lo mismo y no tener que preocuparse por los derechos de acceso del usuario en su disco.
La ubicación estándar es:
C:/Documents and Settings/All Users/Application Data/MyApp
o
C:/Documents and Settings/%Username%/Application Data/MyApp
(también conocido como %UserProfile%/Application Data/MyApp ) que coincidiría con su requisito de permiso de nivel de usuario . También separa los registros creados por diferentes usuarios.
Utilizando el tiempo de ejecución de .NET , estos se pueden construir como:
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
o
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
seguido por:
MyAppDir = IO.Path.Combine(AppDir,''MyApp'')
(Que, con suerte, también asigna perfiles de Vista ).
Personalmente, no me gusta usar el Registro de eventos de Windows donde estoy ahora porque no tenemos acceso a los servidores de producción, por lo que tendríamos que solicitar acceso cada vez que quisiéramos ver los errores. Desafortunadamente, no es un proceso rápido, por lo que su solución de problemas se ve completamente afectada al esperar a otra persona. Tampoco me gusta que se pierdan entre los de otras aplicaciones. Claro que puedes ordenar, pero es solo un poco de un nucance desplazándose hacia abajo. Lo que use terminará siendo una combinación de preferencia personal junto con las limitaciones del entorno en el que está trabajando (archivo de registro, registro de eventos o base de datos)
¿Ha considerado ingresar el visor de eventos en su lugar? Si desea escribir su propio registro, sugiero el directorio de configuración de la aplicación local de los usuarios. Haga un directorio de productos debajo de allí. Es diferente en una versión diferente de Windows.
En Vista, no puede poner archivos como este bajo c: / archivos de programa. Te encontrarás con muchos problemas.
En .NET, puedes encontrar esta carpeta con esto:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
Y el registro de eventos es bastante simple de usar también:
http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx
El registro de eventos de Windows es definitivamente el camino a seguir para registrar los errores. No está limitado al registro "Aplicación", ya que es posible crear un nuevo destino de registro (por ejemplo, "Mi aplicación"). Es posible que deba hacerse como parte de la configuración, ya que no estoy seguro si requiere privilegios administrativos o no. Hay un ejemplo de Microsoft en C # en http://support.microsoft.com/kb/307024 .
Windows 2008 también tiene el reenvío del registro de eventos, que puede ser bastante útil con las aplicaciones de servidor.
Estoy de acuerdo con Lou en esto, pero prefiero configurar esto en un archivo de configuración como dijo Joe. Puedes usar
valor de archivo = "$ {APPDATA} /Test/log-file.txt"
("Prueba" podría ser lo que desee, o eliminar por completo) en el archivo de configuración, que hace que el archivo de registro se escriba en "/ Documents and Settings / LoginUser / Application Data / Test" en Windows XP y en "/ Users / LoginUser / AppData / Roaming / Test en Windows Vista.
Solo estoy agregando esto porque pasé demasiado tiempo pensando en cómo hacer que esto funcione en Windows Vista ...
Esto funciona como está con las aplicaciones de Windows. Para utilizar el registro en aplicaciones web, encontré la entrada de blog de Phil Haack en este un gran recurso: http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx
Personalmente, sugeriría usar el registro de eventos de Windows, es genial. Si no puede, escriba el archivo en el directorio ApplicationData o en el directorio ProgramData (Datos de la aplicación para todos los usuarios en Windows XP).
Ponlo en el directorio de la aplicación. Los usuarios necesitarán acceder a la carpeta para ejecutar y ejecutar la aplicación, y usted puede verificar el acceso de escritura al inicio de la aplicación.
El registro de eventos es difícil de usar para solucionar problemas, pero aún así debe publicar errores importantes.
EDITAR - Debe buscar en los bloques de aplicación MS para iniciar sesión si está utilizando .NET. Realmente hacen la vida más fácil.
Jeez asesinos de karmas. La próxima vez ni siquiera les ofreceré una sugerencia cuando el póster muestre una publicación incompleta.