I'm writing this code in a Console Application targeting the .NET Framework 4 Client Profile.
this.container.AddFacility<LoggingFacility>(
f => f.LogUsing(LoggerImplementation.Log4net));
When it runs, it fails with a type conversion error.
Could not convert from 'Castle.Services.Logging.Log4netIntegration.Log4netFactory,Castle.Services.Logging.Log4netIntegration,Version=2.5.1.0, Culture=neutral,PublicKeyToken=407dd0808d44fbdc' to System.Type - Maybe type could not be found
This is because the Castle.Services.Logging.log4netIntegration assembly is not copied to the output folder. As an runtime-only dependency, this doesn't break the build.
Looking at the build process, I found that it was not copying log4net or the Castle facility assembly because they depend on System.Web which is not available in the Client Profile. Changing to the standard profile means that this dependency is available and the facility can be added.
Why is this be done? What difference does it make that I am not targeting the client profile in a console application designed to be used as a scheduled task on a server?
Some of the appenders depend on System.Web such as the AspNetTraceAppender. The only other option available to the developers would have been to split out components that don't depend on the System core into separate assemblies but that would have broken the beauty of log4net in that it is so simple to use. Additionally at the time of writing log4net I don't believe there was such a thing as a Client Profile.
Since log4net is open source there is nothing stopping you from downloading the source and removing the offending classes and creating your own Client Profile centric log4net assembly.
http://www.thecodeking.co.uk/2010/08/making-log4net-work-with-net-client.html
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With