¿Por qué Log4Net no está creando archivos de registro en producción?

Question

Estoy usando VS2005, un proyecto de sitio web, un proyecto de implementación web y Log4Net. Puedo usar el registro cuando estoy desarrollando localmente. Puedo ver los archivos de registro y todo está bien. Cuando construyo mi sitio web, (utilizando el proyecto de implementación web), utilizo el despliegue como una sola opción DLL. Cuando compruebo las ubicaciones donde deberían estar mis archivos de registro, no puedo ver ningún archivo.

¿Hay alguna manera de solucionar este problema? No creo que agregar el valor de depuración a la configuración de la aplicación sea útil porque no tengo una consola porque es un sitio web.

EDIT No quiero que las 150 repeticiones se desperdicien una última vez. Comparé la traza interna de mi entorno de desarrollo con la traza de la producción. El seguimiento de mi entorno de desarrollo muestra la llamada al Configurador Xml, donde el de producción no. Tengo un código en el método global.asax en application_start(). Puse código de depuración allí y se llama en dev pero no en producción.

Creo que es aquí donde el proyecto de implementación web está causando algunos problemas. ¿Global.asax se compila en una sola DLL? Cuando hago una compilación en el directorio de implementación, veo un archivo global.compile. ¿Debe ir esto a la carpeta bin en producción? ¿O es el código global.asax en la única DLL? Tener ambos en la carpeta bin o solo en el DLL no cambió nada.

Answer 1

he encontrado el problema. Los permisos fueron CORRECTOS. Resulta que el uso de un proyecto de implementación web también crea un archivo precompliled.config en la raíz. No había copiado eso a la cultura de la producción. Tan pronto como estuvo en eso, todo funcionó. Lo siento, nadie recibió la recompensa.

Answer 2

Esto me ha pasado antes y tenía permisos en el usuario de ASPNET para crear los archivos necesarios. ¿Se puede verificar si hay algo en el registro de eventos de Windows que indique esto?

Para verificar el tipo de cosas (observamos al observador!) Sacamos donde el log4net iba a funcionar escribiéndolo usando el OutputDebugString() via pinvoke.. También lo colocamos en un try catch para asegurarnos de que descubrimos errores con respecto a esto, ya que es muy importante usarlo para poder iniciar sesión correctamente.

Answer 3

¿El proceso de trabajo tiene suficientes privilegios para escribir en el directorio de registro? Supongo que ese no es el caso. Es posible que desee otorgarle al grupo de procesos de trabajo derechos para escribir en el directorio y ver si eso soluciona su problema.

Answer 4

Compruebe los permisos en el directorio de salida esperado y asegúrese de que el servicio web pueda escribir en él. La forma más sencilla de hacerlo es ejecutar filemon.exe (una aplicación SysInternals) y restringirlo en consecuencia. Esto debería indicarle si algo falla y puede corregirlo según sea necesario

Answer 5

Asegúrese de que log4net get esté configurado correctamente. ¿Tal vez el dll está bien pero falta el archivo de configuración? log4net podría estar allí, pero simplemente no tiene ningún apéndice activo.

Answer 6

para asegurarse de que si log4net está configurado correctamente, sí creo un Appender UDP que se conecta al puerto 9090. Utilizo la motosierra http://logging.apache.org/chainsaw/index.html para verificar las entradas del registro.

con esto usted puede verificar que al menos se hayan realizado algunas entradas de registros y que el registrador se esté ejecutando.

UDP Config Appender de

<appender name="UdpAppender" type="log4net.Appender.UdpAppender"> 
     <remoteAddress value="localhost" /> 
     <remotePort value="9090" /> 
     <layout type="log4net.Layout.XmlLayoutSchemaLog4j"> 
      <locationInfo value="true" /> 
     </layout> 
</appender> 

motosierra XML

<?xml version="1.0" encoding="UTF-8" ?> 
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> 
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">  
    <plugin name="LocalReceiver" class="org.apache.log4j.net.UDPReceiver"> 
     <param name="Port" value="9090" /> 
    </plugin>  
</log4j:configuration> 

Answer 7

Parece que la raíz de su problema es que el evento Application_Start en Global.asax no se está disparando.

Existe un problema "conocido" al implementar desde VS 2005 a Windows 2003, que el Application_Start no se inicia.

El contenido de Global.asax.cs se compilará en la dll. Pero el Application_Start no se ejecutará a menos que el archivo Global.asax esté presente.

Aquí hay un par de enlaces de interés:

http://accidentaltechnologist.com/asp-net/application_start-not-firing-and-the-globalasax/

http://www.velocityreviews.com/forums/t300292-web-deployment-projects-globalasax-problem.html

Hay algunas otras posibilidades que están cubiertos en los enlaces anteriores.

Esperanza esto ayuda

Shiraz

Answer 8

Añadir esta en el archivo AssemblyInfo.cs y comprobar

[assembly: log4net.Config.XmlConfigurator(Watch=true)]