Also using Entity Framework as ORM so using Beta Oracle driver for that connection.
However, we want the logger to use a different connection (although the same driver is being used) to the database.
Locally, the logger was not able to log messages to the database - turning on tracing via system.diagnostics congfiguration enabled me to see that the Log4Net service was not able to connect to the database.
To turn on tracing:
<system.diagnostics> <trace autoflush="true"> <listeners> <add name="textWriterTraceListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="c:\temp\log4net.txt" /> </listeners> </trace> </system.diagnostics>
The message in the log4net.txt file:
log4net:ERROR [AdoNetAppender] Could not open database connection [data source=DBNAME;User ID=USER;Password=PASSWORD]
What i didn't realise is that in production environments, Entity Framework was configured to find the Oracle Driver DLLs in a specific folder within the application (eg DeployDLLs) but locally, it was using the driver in the GAC.
The problem was that the Log4Net service was not looking for the Oracle Driver DLL in the GAC...
So the solution was to copy the Oracle Driver DLLs into the 'bin' directory of the MVC project.
Now the Log4Net service was able to access the Oracle Driver DLLs, connect to the database and write my messages to the log table.
What this problem does demonstrate is: if the Log4Net service cannot connect to the database, the application still runs without a glitch - a good thing for users. However, not a good thing for support team because there is no indication that this failure was happening apart from the entry in the log4net.txt file from the Tracer...
What would be ideal is to have an email sent to the support team whenever the logger fails to connect to the database...