asp.net mvc - Log4Net works on Dev machine, fails when deployed to shared host (using same db/connstring)

Question

I have log4net configured and working fine on my local machine, however when I deploy to my host (godaddy) it fails silently. I am using the same database/config file on my dev machine, and on the host. My log4net reference is set to copy local, and the log4net.dll, .pdb, and .xml exist in the bin on the host. This is an asp.net mvc app.

Edit: No exceptions are thrown, and the application runs as expected (minus the logging)

This is running on SQL Server 2005 The webhost is IIS 7

salient details of my config are:

<root>
  <level value="DEBUG" />
  <appender-ref ref="AdoNetAppender" />
</root>

<appender name="AdoNetAppender" type="log4net.Appender.AdoNetAppender">
  <bufferSize value="1" />

  <connectionType value="System.Data.SqlClient.SqlConnection, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

Anybody have any ideas on things to check?

Answer 1

In my experience, log4net usually swallows any internal errors, simply resulting in log statements that do not produce any results.

What you may want to try is enable log4net's internal logging. You can do this by adding the following to your appSettings section:

<add key="log4net.Internal.Debug" value="true" />

This sets the property LogLog.InternalDebugging to true. log4net will now log to the standard output and error streams and to configured trace listeners.

You can use the following configuration to capture any messages logged to tracing:

<system.diagnostics>
  <trace autoflush="false" indentsize="4">
    <listeners>
      <add name="myListener"
        type="System.Diagnostics.TextWriterTraceListener"
        initializeData="c:TextWriterOutput.log" />
      <remove name="Default" />
    </listeners>
  </trace>
</system.diagnostics>

All messages logged by log4net internally will appear in TextWriterOutput.log. If you get a SecurityException when you add the trace listener to your configuration, then very probably the apppool identity does not have sufficient rights to create a file at the specified location (in the example: c:). Try another location or give the apppool identity sufficient rights.