How to pass parameters set at runtime to the log4net configuration

Today I learnt that it is possible to pass parameters set at runtime to the log4net configuration sections.
We could in example put the following appender in our log4net configuration section:

<appender name="SystemAppender" type="log4net.Appender.RollingFileAppender">
 <file type="log4net.Util.PatternString" value="C:\Logs\%property{LogFileName}.log" />
 <appendToFile value="true" />
 <maximumFileSize value="1000KB"/>
 <maxSizeRollBackups value="2"/>   
 <staticLogFileName value="false" />
 <layout type="log4net.Layout.PatternLayout">
  <conversionPattern value="%date %level %thread %logger - %message%newline"/>
 </layout>
</appender>

Did you noticed the attributes of the file element? Togheter with the usual value, we got also a type, set to log4net.Util.PatternString, and if you double check, you will notice also the value is a bit unusual: part of the string is a %property{LogFileName} substring.
Now, that substring is telling to the log4net to look for a property called LogFileName in its ThreadContext. If you set that property before the call to XmlConfigurator.Configure, as in the following snippet, you will be able to programmatically set it at runtime:

 log4net.ThreadContext.Properties["LogFileName"] = "MyApplication";
 log4net.Config.XmlConfigurator.Configure();

This will set your log file to C:\Logs\MyApplication.log.
This approach can be useful in many scenarios, but probably not so efficient if you wish to multiplex the log entries to different files, because everytime you set the LogFileName property, you need to call again XmlConfigurator.Configure().

Thanks to Max Leifer to show us this technic :)

Installing a missing component on Microsoft SQL Server 2005 sp2

Today to set up a Team Foundation Server I noticed an instance of SQL Server 2005 was already installed on the machine. Unfortunately it was missing the Reporting Service component, which is required from TFS, so I decided to install it.
I thought it should be an easy exercise. I thought so.
First of all, I quickly discovered the service pack 2 had been installed in this machine, but quite irregurarly: that is, some components were on sp2, some others on sp2 pre-5th March, some other one on sp2 post-5th March (if you are not an insider, Bow Ward as a quite revealing explanation of the mess that was sp2).
Following an officemate's advice (cheers Alex!), I decided first to bring everythign at GDR2 (that is 9.00.3054), then I tried to add the missing components (once there, I decided to add also NS, even if I am going to stop it straight away!).
Here is where I discovered (or rediscovered? I am pretty familiar with this argument, but I can't remember to have met this issue before) that SKUUPGRADE is not the same than skuupgrade ..
That said, this is what I got to see when I finally get to choose the components to add:



Isn't that misleading? I mean, what I wish to achieve is to add some component not previously installed (by rule, if not otherwise required by security policies or other issues, I do ever install all the available components, and then disable the services I don't need). This interface clearly leading (me at last) to believe that the Database Services and the other components paired with the red x will be uninstalled, which will not happen. What this is trying to communicate is that the components I have installed on my machine are not the components on the install file, but if so, would be easier to just show that (i.e. showing Database Services as installed, but with the version number in braces).

Yep, all of this was a rant, but when people (well, me ..) have to waste 3 hours of their lives to add a component to an already installed software, there is definitively something smelling bad there ..