Add a DebugLoggerProvider that writes to Debug.WriteLine

[DamianEdwards]

Would be almost identical to the existing ConsoleLoggerProvider but it would write to Debug.WriteLine. It would enable itself only when the debugger is attached.

We should have this provider in the runtime by default so that any app will log messages to the debugger output, e.g. in Visual Studio.

[DamianEdwards]

Something like the one at https://github.com/jongalloway/ndc2015-aspnet5-workshop/blob/master/Labs/4%20-%20Dependency%20Injection%20%26%20Unit%20Testing.md#configure-a-logger-so-you-can-see-the-request-id-messages

[hishamco]

It will be nice if the logger will be added automatically by the runtime if the debugger is attached
👍

[muratg]

@kichalla We can potentially do this in DNX by bringing logging abstractions to DNX layer when you bring ILogger to DNX. Shouldn't be it's own package.

aspnet/dnx#1118

Will require an update in Hosting too.

[davidfowl]

i would avoid the dnx for now and keep it localized to hosting

[DamianEdwards]

@davidfowl any particular reason? Because of the churn we're expecting in the DNX? We have other issues RE bringing the LoggerFactory down to DNX so it seems odd to not do it all at once.

[davidfowl]

Putting things int the dnx requires care in order to avoid pinning before the application loads. That plus the currently refactoring going on it seems unwise to make that layering decision at this point. We need an easy way to move things without pinning it before the app runs

[DamianEdwards]

If that's the case why don't we just put it in the templates only? Hosting still isn't really optional for apps anyway so maybe better to require it to be added by the app explicitly.

[davidfowl]

+1. We should at least do the feature for beta6 it's trivial. We can discuss moving it in by default at a later date.

[DamianEdwards]

K. What package should we put it in? Microsoft.Framework.Logging?

[davidfowl]

Separate package like the other providers