I've checked the connection string (I got it from the server explorer).
I've checked the commandText in log4net config.
I've checked the database permissions (integrated security is fine and works outside of the log4net class).
I've checked the repository's configured property (it is configured, it finds the config file fine).
I've also checked that the fields defined in the config file match the attributes (field size etc.) of the table in the database.
Any ideas?
When I'm debugging it seems to be hitting all the right methods at all the right times, with no exceptions raised.
<log4net>
<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" />
<connectionString value="" />
<commandText value="INSERT INTO dbo.Log4Net ([Date],[Thread],[Level],[Logger],[Message]) VALUES ('01-01-2001', 'test', 'test', 'test', 'test')"/>
<!--<commandText value="INSERT INTO dbo.Log4Net ([Date],[Thread],[Level],[Logger],[Message],[Exception],[MachineName],[CultureId],[SourcePage],[Details],[Method]) VALUES (@log_date, @thread, @log_level, @logger, @message, @exception, @MachineName, @CultureId, @SourcePage, @Details, @Method)" />-->
<parameter>
<parameterName value="@log_date"/>
<dbType value="DateTime"/>
<layout type="log4net.Layout.RawTimeStampLayout"/>
</parameter>
<parameter>
<parameterName value="@thread"/>
<dbType value="String"/>
<size value="255"/>
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%thread"/>
</layout>
</parameter>
<parameter>
<parameterName value="@log_level"/>
<dbType value="String"/>
<size value="50"/>
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%level"/>
</layout>
</parameter>
...more parameters
<securitycontext type="log4net.Util.WindowsSecurityContext">
<credentials value="Process">
</credentials>
</securitycontext>
</appender>
<appender name="FileAppender" type="log4net.Appender.FileAppender">
<param name="File" value="LogTest.txt"/>
<param name="AppendToFile" value="true"/>
<layout type="log4net.Layout.PatternLayout">
<param name="ConversionPattern" value="%d [%t] %-2p %c [%x] - %m%n"/>
</layout>
</appender>
<root>
<appender-ref ref="ADONetAppender"/>
<appender-ref ref="FileAppender"/>
</root>
</log4net>
It's writing to neither appender.
Try to enable log4net self-logging, maybe it'll help to find out:
per the ADONetAppender config example:
This uses the ADO.NET parameterized query format, so you need to use that syntax. Additionally, you may not want to use integrated security for the db connection (esp. if you are running a web site or a service). For your file appender, I recommend a fully qualified path, and make sure it is writeable by the logger.
I assume you have already created the table in the specified database?
NOTE I recommend setting the trace appender in Debug mode too, to make sure you are actually logging stuff.
Add this line in the AssemblyInfo.cs file
As the official configuration manual states "The log4net configuration can be configured using assembly-level attributes rather than specified programmatically", which I found as a more clear approach. Some people might find my answer as a more straightforward.
Source: https://logging.apache.org/log4net/release/manual/configuration.html
Right, after hours of pulling my hair out - I've cracked it.
This line:
Needed putting in prior to any logging (well, as early as possible in the app). That's it. That was all it took. This is one of those problems were I'm extremely relieved but frustrated at the same time.
I ran into a similar issue yesterday, Log4Net was just not writing to the database. I copied the configuration from another existing appender that successfully writes logs to the database. My solution was to run SQL Server Profiler to try and catch what was happening. Profiler showed that the INSERT statements were being sent by Log4Net, but it was failing on the SQL Server side. Manually running the INSERT statement in SQL Server Management Studio showed me exactly what was wrong with it, in my case, it was inserting NULL into a column that didn't accept NULL.
for sql server connectivity I'm using my live account to login to azure and sql server and due to that I had to change integrated security to "SSPI" instead of "true" did the trick
only found out it was the con string by adding this