This project has moved and is read-only. For the latest updates, please go here.

log4net writing to file

Topics: General Questions
Jul 30, 2010 at 12:31 PM

I tried to integrate log4net into a biztalk application, and I'm using the following code (just a sample method in my codebehind class):

public class Logger
        public static void Test()
            PropertiesCollectionEx logProps = new PropertiesCollectionEx();
            SLog logger = log4net.Ext.Serializable.SLogManager.GetLogger("xxxx\\yyyyy", log4net.helpers.CallersTypeName.Name);
            logProps.Set("InstanceId", Guid.NewGuid());

            logger.Debug(logProps, "Biztalk test.");

Writing into the database via the Ado-Connection works, but writing to a file behaves weird. The BT locks the file (ok) but the content appears not until I restart the host instance.

Configuration goes like this:

<appender name="File" type="log4net.Appender.FileAppender">
        <layout type="log4net.Layout.PatternLayout">
            <param name="ConversionPattern" value="%d [%t] %-5p %c - %m [%P{InstanceId}] %P%n" />
		<param name="File" value="e:\\xxxx\\LogFiles\\yyyy.log" />

I also noticed that the registry-keys are not copied to the WOW-Key, as probably should be the case if I use a 32bit instance on my 64bit machine. Another small drawback is, as I want to use a Subkey in the registry (works with yyyy\zzzz as Name), that the key will not be generated by the deployment framework. I will probably hack the target-file for that.

thanks for any help!



Jul 30, 2010 at 5:49 PM


To be honest, I have not used log4net for many years, so hopefully someone else can jump in, but I have a few references for you.  I would guess that the reason the log file is not populated until you restart the host instance is write buffering.  Evidently recent versions of log4net include an ImmediateFlush attribute on TextWriterAppender -- not sure if that would apply to FileAppender.  I also found this on

The registry key issue is known -- the trouble is that .NET 3.5 can't arbitrarily target either 32-bit or 64-bit registry views.  There might be some workaround way that I could do it, just with a .reg file or something.  I thought it would be very simple to fix, but it turned out to be more difficult.

All that said, if your goal is to log to a file, I highly recommend using the "Best Practices for Instrumenting High Performance BizTalk Solutions" guidance instead of log4net or Enterprise Library.  Performance is dramatically faster and you can dynamically enable and disable logging at runtime.  It uses Event Tracing for Windows (ETW), the same high-performance logging system that BizTalk itself uses (in addition to most Windows services on newer server versions).  It's very easy to use.  Unfortunately they did not sign the DLL, so you need to add your own strong name key and build it yourself.  Here are the links:  article and code.


Aug 2, 2010 at 2:17 PM

Hi Tom,

thanx for the infos. The problem with the file seems to have originated from the notepad++ locking the file in some way.

I presented the log4net integration to my client. He absolutely dislikes the idea that the config file location is stored in the registry. Is the source code für the log4net.Ext component somehow available so that I can provide another way to instance it (providing the location as parameter and read it before from client specific SSO read routine)?

Furthermore, is there a log4net way to check if a trace statement got written? I want to write monitoring statements to the database, but if the database is down, I do not want the BizTalk Server to continue.

Also thanks for the article. I'll study this - maybe it is something we can incorporate.


Aug 2, 2010 at 6:37 PM


The source code for Log4net.Ext is included.  If you do a Complete install, a ZIP file is installed that contains all of the source code.  I noticed that it includes both RegistryConfigurator and AppConfigConfigurator classes.  I don't know if the latter would be better for you or not.

I am not too familiar with log4net myself (it was built in to the Deployment Framework many years ago), but I would be wary of synchronous logging calls out of BizTalk, especially to a database.  That could really destroy your BizTalk app performance.  There may be a way to do it, but you should check on a log4net specific forum.


Aug 2, 2010 at 7:20 PM

You should be able to get your config file location out of the registry and into something more suitable pretty easily - let me know if you have questions after you've had a look at the source Tom references.  

You should indeed test with log4net for your particular performance requirements, but the provided appenders are generally pretty careful about how they deal with multiple threads, contention over files, etc.  As I recall, there is a buffered appender that you can place "ahead" of the file appender if desired.