I've tried porting NLog to Metro-style/WinRT a couple of times, and I've surrendered both times within hours of starting. The problem with NLog is that it's amazing, rich surface area extends all the way over the Metro-style surface area. Whereas in .NET Full you have Console, Debug, and Trace, in .NET Core you only have Debug. Talking cross-process is out. There's no event log support (which is a mistake in my book). The file API is synchronous. Queuing is hard, etc. In short, although NLog will run on anything and is fantastic, it's too big a solution for Metro-style very focused capabilities.
What I see as the total surface area of logging on Metro-style is being able to send information to Debug.WriteLine, and also to dump out crash reports to disk, or maybe HTTP. Don't forget that Debug.WriteLine ends up in OutputDebugString and hence in the regular Windows debug stream. You can use DbgView to surface information outside of the process, which is helpful if your Metro-style process won't start. Likewise, dumping a file to disk on ERROR or FATAL is also helpful - providing you can write it before you're scrubbed out of memory.
To that extent, I've put together MetroLog
. This is a first pass over a very basic logging framework that's optimised for Metro-style/WinRT development. It's not intended to become huge like NLog.
I think splitting it is actually quite workable. For the most part you're actually just using a tiny amount of NLog functionality in your actually running
code. 99% of calls to the NLog library
are Log.Info(...), etc, and these are easily shimmed out. I would go far to say that clipping NLog so that it fits into Metro-style is rather over-thinking the problem.
I've tried to keep the construction compatible, whilst lightweight. So you still have LogEventInfo
, and Logger
. It could be that these two libraries converge again in the future, or it could be as @davkean
suggested that actually it make sense to restructure the lot around Portable Class Libraries.