Confusing problem with log4net

I’m using log4net for logging in my ASP.NET application. This web site is based on .Net framework 3.5 and is installed on IIS 7.5 and Windows Server 2008 R2 in a 64 bit machine. Logging was working greatly when I was running application from Visual Studio 2010’s internal web server, but was not working at all when run from IIS.

First thing that I thought about was permission. So I grant full access to network service with the folder containing application: “c:inetpubwwwrootmyapp”. But this didn’t work and no log file generated. As I’m new to Windows Server 2008, I tried to grant full permission to all users that I knew: IUSR, local service, aspnet, IIS_IUSRS, Everyone, etc. But still nothing was working. A question in SO caused me to think this is because of trust level, so I set my application’s trust level to full. But still nothing was working. Another question in serverfault.com caused me to think the problem root is that Windows Server 2008 is using a new user for IIS. So I tried to use icacls to add ApplicationPoolIdentity to permission list. After it, I tried to change Identity of DefaultAppPool to Network Service. But none of this two solutions solved my problem.

Some people have been recommending to enabling internal logging of log4net to detect original problem. And yes, this showed me what was the problem:

log4net: XmlConfigurator: config file [C:inetpubwwwrootlog4net.config] not found. Configuration unchanged.

After some investigations, root cause was detected. It was due to incorrect use of Server.MapPath. I was forgotten to add a tilde mark in beginning of log4net.config’s path. When I used Server.MapPath as follow, all headaches have suddenly disappeared and my log file appeared and get working as I was desiring:

XmlConfigurator.Configure(new FileInfo(Server.MapPath("~/log4net.config")));

A wrong path has been causing log4net to search c:inetpubwwwroot for log4net.config not my application’s path at c:inetpubwwwrootmyapp. All this nightmare was because of my own mistake not Windows, IIS or .Net!