Question

I have been working on getting log4net working in a demo program for a client so they can integrate it with their code base. I found this article when doing the implementation http://www.codeproject.com/Articles/14819/How-to-use-log4net, and
one of the steps described is

Step 2: Add below line in your AssemblyInfo.cs file.

[assembly: log4net.Config.XmlConfigurator(ConfigFile="Web.config", Watch=true)]   //For log4net 1.2.10.0

and as soon as I added that line of code to my AssemblyInfo.cs the logger started working.

I did some Googling around the place to try to understand why this line is required, and most documentation and comments claimed AssemblyInfo is for optional configuration information. I don’t understand why adding this line would have made my program work;
my key questions are
– how does the configuration information in AssemblyInfo.cs get picked up and used (and is there some documentation that describes this clearly)
– how did log4net “know” to pick up that information from AssemblyInfo.cs?

I understand from What does the assembly keyword mean in the AssemblyInfo.cs. Does it permit to use method inside? that these are attributes on the assembly but not the mechanism behind it.

Answer 1

Nice topic. I cannot provide a link, as you are asking, only few points, findings. Some of my statements could be known and obvious. I am trying to put them together here, in one place. And give the answer how that magic with log4Net setting is triggered.

• AssemblyInfo.cs is a “normal” file, as any other .cs file, containing e.g. C# class definition. In a project file it is marked as “compile”.
  Other words, this is a place chosen by convention, where all “assembly” attributes should be placed. But they could be (but should not) anywhere (if placed outside of a specific namespace declaration in any of project compiled files).
• Any custom attribute, like log4Net “XmlConfiguratorAttribute” could be added to assembly definition, if marked as [AttributeUsage(AttributeTargets.Assembly)].
• All attributes are just a meta information. Other words they are available (for reflection), but not used implicitly. Not executed by default.
• (some Attributes like AssemblyVersion, AssemblyTitle seem to be executed, but it is intended and explicit call mad by compiler)

Given this, what we can do with attributes. Our (custom) code is allowed to use reflection to check if there is an Attribute, mostly of a specific known type (e.g. XmlConfiguratorAttribute). If such Attribute exists, we can “execute” it. For example. I am using ASP.NET MVC having its “runtime” which grants that any Attribute of a type IFilter will be executed properly. It is the MVC runtime, observing classes and methods and explicitly executing these Attributes.

The solely stated attribute declaration inside of the AssemblyInfo.cs is not enough. As in the snippet above where XmlConfiguration is declared. Usally there will be some other call (in ASP.NET maybe in Global.asax) constructing the ILog

ILog logger = LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);

Well, and somewhere in the flow of methods call-chain, inside of the Log4Net will be a check if exists:

var attributes = Attribute.GetCustomAttributes(thisAssembly, typeof(XmlConfiguratorAttribute));

and if yes (assembly has such attribute) – log4Net can use it, force it to do its job (e.g. configure itself from xml)