I started a new project recently and set about adding log4net to it. I’d upgraded to a new Window 7 workstation over the past month whereas I’d previously been using XP, so the step up to IIS7 was exciting and and a bit anxious all at the same time. My first hurdle so far has been using log4net.
I tend to be the type of person that likes to separate out the log4net configuration into it’s own file, usually log4net.config. Setting up this new project; however, I started running into a problem I’d never seen before. When trying to use the XmlConfiguratior to read my log4net.config, I would see this exception:
[SecurityException: Request for the permission of type ‘System.Security.Permissions.FileIOPermission, mscorlib, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b77a5c561934e089’ failed.]
Searching for others with this problem has not yielded much success. I’ve seen articles stating that it’s an issue with medium trust security (on m local workstation trust was set to full) to problems with some sort of breaking code within log4net itself. Most of these articles I suspect were not using IIS7, but it was hard to tell.
I ended up digging into the log4net source code to find out what was happening. The problem would occur on a line of code that tried to access the FullName property of a System.IO.FileInfo object. That property threw the exception worked fine it I tried to access it from my web project, but once it got down into the log4net guts, it would not.
After a lot of frustration, I finally started looking elsewhere. I ran across a comment on Stack Overflow that stated they used .xml instead of .config files. I had dismissed it due since others claimed .config files where fine, but recalling what I’d seen there I decided to try it. *Poof* it worked!
I didn’t really want to leave the configuration in a file with the .xml extension since that could easily be downloaded from a server. The discovery told me that it was likely due to something IIS was doing with ASP.NET to hide files, but the odd thing was that it could read from the web.config, so I was a little perplexed. I started digging into how IIS7 handles these types of protected files.
It turns out that there’s a section in the hosting configuration that lists protected files under the name “requestFiltering”. Hmm…that was an interesting sounding name. Unfortunately all the entries were only by file extension, not by file name directly so there had to be something else.
I ended up in the IIS7 Manager application and found the Request Filtering area. I began to poke around in there and discovered another tab called Hidden Segments which had an entry for the web.config! I clicked the Add Hidden Segment link under Actions and added a new entry for log4net.config and viola, my application worked!
I know that most of the IIS7 configuration settings are stored in various config files, including the web.config, so I started looking in there and found this new element in the <system.webServer> section.
I believe that including this section will allow the files to work. I even changed my trust level in my dev environment to Medium and it still ran just fine.
There may be other things that can cause this sort of problem, but this fixed my example. Hopefully this helps someone else out there as it was a bear to track down!