.net - ¿Hay alternativas a Common.Logging?
nlog (3)
EDIT: Common.Logging 2.1.1 se lanzó el 9 de junio de 2012 y la página de Github es bastante activa, con el autor comentando específicamente sobre la salud del proyecto .
Estamos considerando el uso de Common.Logging en un nuevo proyecto .NET, pero me preocupa un poco que el proyecto parezca estar inactivo. La Common.Logging se actualizó por última vez en 2009 y la última versión disponible en SourceForge se creó en 2010. Ya encontré una incompatibilidad con NLog 2 y me preocupa que esto pueda convertirse en un problema mayor con el tiempo. Me he dado cuenta de que Enterprise Library 5.0 no aparece como compatible, pero no lo he probado.
¿Hay alguna otra alternativa que proporcione una interfaz común similar?
He estado usando Common.Logging durante cuatro años, y puedo usarlo con NLog2. Para responder a su pregunta a fondo, debemos examinar más de cerca a Common.Logging primero. Common.Logging te da dos beneficios:
Desde 1.x, Common.Logging le permite escribir su aplicación independientemente del marco de registro. Por lo tanto, puede cambiar fácilmente de un marco de registro a otro sin tener que volver a compilar su aplicación. Esto es particularmente útil para el desarrollo de una biblioteca común, que puede ser utilizada por varias aplicaciones que utilizan diferentes marcos de trabajo de registro.
A partir de 2.x, Common.Logging le permite agregar la información de registro de varios marcos de trabajo de registro. Digamos que estamos desarrollando una aplicación y queremos aprovechar dos bibliotecas de la tercera parte, digamos A3rd.dll y B3rd.dll. A3rd.dll usa log4net, pero B3rd.dll usa NLog. Ahora, ¿cómo consolida la información de registro de A3rd.dll y B3rd.dll en un archivo de registro (o sistema de monitoreo de registro)? Common.Logging puede ayudar, por ejemplo, puede capturar el mensaje de registro de NLog y enviarlo a log4net, y luego dejar que log4net lo escriba en el archivo de registro o lo envíe a cualquier lugar que log4net pueda hacer.
Ahora, de vuelta a NLog2. La API de registro en NLog2 es compatible con versiones anteriores de NLog1, pero se modificó la API para la configuración y la segmentación. Entonces, si todo lo que necesita es enviar el mensaje de registro a NLog2, simplemente puede hacer una redirección de ensamblaje (vea mi respuesta aquí: ¿Se puede usar NLog v2 con Common.Logging )?
Dicho esto, si desea agregar un mensaje NLog2 a otro marco de registro utilizando Common.Logging, el enfoque de redireccionamiento del ensamblaje no funcionará. Se debe crear un adaptador NLog2 específico.
Como dijo @Kugel, inactivo podría significar estable y maduro. Como Common.Logging funciona con varios marcos de registro, es poco probable que se publique una nueva versión cada vez que uno de los marcos de registro admitidos elabore un lanzamiento. De lo contrario, podría ser más confusión que ayuda. Por lo tanto, el redireccionamiento del ensamblaje siempre debe considerarse primero. Solo cuando realmente surja un problema de incompatibilidad, como mencioné sobre el redireccionamiento de mensajes de NLog2, envíe un correo electrónico a la lista de correo y estoy seguro de que alguien intervendrá y ayudará.
Saludos, Kenneth
Parece que hay algo en esta área del proyecto bclcontrib-abstract :
Después de haber probado el BclContrib-Abstract.NLog 0.1.5 , no me gusta la forma en que se encuentra debajo del espacio de nombres de Contoso ( Contoso.Abstract.NLog ).
Si quiero usar una biblioteca no compatible (por ejemplo, NLog2) parece que una opción sería implementar un FactoryAdapter personalizado. No estoy seguro de lo difícil que sería esto, pero podría ser una opción:
Si desea conectar una biblioteca de registro nueva, pero no compatible, debe proporcionar un adaptador de fábrica de registrador que implemente la interfaz Common.Logging.ILoggerFactoryAdapter. Los registradores deben implementar la interfaz Common.Logging.ILog.
Actualizar:
Aquí está mi primer intento de una implementación para NLog 2, usar bajo su propio riesgo. Cualquier comentario bienvenido: