Since we are breaking the API with respect to logging in 0.15, I figured we may as well take advantage of it and switch from ILog to ILogProvider at the same time, so we can do things like #1008 and also allow scripts, script packs, modules etc. create their own named loggers.

Note that this does not detract in anyway the options listed at #996 (comment). If we decide to go with option 3, i.e. a deprecation of Common.Logging by maintaining the Common.Logging overloads, we can still do that, by adding them back in, which we leave us with both Common.Logging.Ilog and ScriptCs.Contracts.ILogProvider overloads.

Trying to figure out what happened with the CI build.

Works On My Machine™

That turned out to be rather subtle. The tests were all passing in VS with whatever test runner I tried, but were failing on the command line. I then switched VS to release config and it also failed. I tracked it down to this https://github.com/adamralph/scriptcs/blob/871c88bee11ec0130e9383eee52f26a2a4552960/src/ScriptCs.Contracts/Logging/LogProviderExtensions.cs#L14

The JIT was inlining the method in the release build which fatally altered the stack, causing this particular piece of magic to fail. It's the same method as used in LibLog so it's proven to work (https://github.com/damianh/LibLog/blob/69873d63d382073ac16266a071654fb01fdd4b46/src/LibLog/LibLog.cs#L438-L439) but over there it's not an extension method so it doesn't get inlined. I tried splitting it into two lines to match the LibLog impl. exactly but it made no difference.

I guess LibLog may also be liable to this problem, but it's been getting lucky so far just because of the way that the JIT heuristics work out. I'll probably raise an issue over there for consideration.

You could try adding a MethodImpl attribute with MethodImplOptions.NoInlining. See https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions(v=vs.110).aspx

Uh. Looks like that's already done. Damn mobile views...

I added a commit to fix #1010

Before:

C:\code>scriptcs awol.csx
ERROR: Could not find file 'C:\code\awol.csx'. - 'C:\code\awol.csx'.

C:\code>

After:

C:\code>scriptcs awol.csx
ERROR: Error executing script 'awol.csx' [FileNotFoundException] Could not find file 'C:\code\awol.csx'.

C:\code>

As far as I can see, this PR now completes all the logging changes envisioned so far.

It is using the latest version of LibLog (4.1.1) which contains a new feature which I contributed (damianh-archive/LibLog#56) allowing LibLog to function purely as a provider of out of the box support for common logging frameworks and sitting, internally, underneath the public logging API of the consuming library.

To summarise:

• ScriptCs.Contracts defines it's own public logging API, decoupled from LibLog, with the initial definition copied from LibLog (because it's very good).
• All types in other projects now accept ILogProvider parameters instead of ILog to allow specific loggers to be created to support features such as Show logger name at debug and trace level #1008
• ScriptCs.Contracts provides a DefaultLogProvider which uses LibLog providers internally to provide out of the box support for common logging frameworks. This is not used by scriptcs.exe. It is purely for hosts.
• ScriptCs.Contracts provides a NullLogProvider as a cheap way for hosts to disable logging without having to install a logging framework and provide a null config (LibLog logs to the console by default)

To clarify, these changes are independent of the decision we take regarding breaking changes for 0.15 (see #996 (comment)). If we do decide to reinstate the Common.Logging overloads for a transition period then this can be done later, independently of these changes.

rebased

Added one more commit: LibLog 4.2 no longer logs to the console by default which removes the need to publicly expose NullLogProvider for hosts to switch this off. They can just use DefaultLogProvider in all cases.

Rebased and upgraded to LibLog 4.2.2

rebased

LGTM