1

Currently depending on a library which utilizes the Castle.Core Logging abstraction. I've dug through both that library's docs, and Castle's, and can't seem to find clear explanation of how to capture log output to pipe to our logging framework of choice (NLog, in this instance). I've also dug through a few posts which touch on the topic, but dismissed as not applicable to this situation.

It should be noted that NLog works fine for the rest of the application. No errors seen in the internal logs. Just no output from this third party library.

I see the Castle.Core NLog integration, but that looks to be something to be utilized by the library depending on Castle, not one depending on the library.

So is it possible to capture log output from this library? Or do I need to reach out to the project for support?

Community
  • 1
  • 1
ReservedDeveloper
  • 414
  • 3
  • 19
  • For additional context, the library in question is [TestStack.White](https://github.com/TestStack/White). I'd have mentioned it in the body, but figured this question would apply to any library using Castle's logging. – ReservedDeveloper Dec 12 '16 at 15:17

1 Answers1

1

If you own the process hosting the library, it is your responsibility to tell Castle.Core.Log which log provider to use.

Configure NLog in your application, then register NLog as the Castle Log Provider as explained in the documentation by calling
container.AddFacility<LoggingFacility>(f => f.LogUsing(LoggerImplementation.NLog) when creating your container

For your library (white) you should provide the logger factory by either setting it on the CoreAppXmlConfiguration instance, or supply your own subclass instance when initializing the library's Application object.

See https://github.com/TestStack/White/blob/master/src/TestStack.White/Configuration/CoreAppXmlConfiguration.cs#L53

Florian Doyon
  • 4,146
  • 1
  • 27
  • 37
  • I tried the XML configuration approach, but didn't catch the note that code config is preferred. I'll give this a crack! – ReservedDeveloper Dec 12 '16 at 16:57
  • Remember that NLog also needs to be configured, so you can end-up with a bad NLog configuration that doesn't complain. Use `throwExceptions="true"` and `internalLogLevel="Debug"` in the `` root tag of your `NLog.config` file. – Florian Doyon Dec 12 '16 at 16:59
  • Unfortunately, this project isn't using Castle Windsor, so no access to the container mentioned. And the library in question only uses Core. – ReservedDeveloper Dec 12 '16 at 17:04
  • Yeah, I should update the original to reflect that NLog is piping output just fine aside from capturing this library. – ReservedDeveloper Dec 12 '16 at 17:05
  • This ended up being the trick. I had to put it in an unexpected spot due to some runtime compiling, which is likely what was tripping up the XML approach as well. Thanks! – ReservedDeveloper Dec 13 '16 at 20:18