It would be nice to have access to some sort of low-level logging, as I would have in a plain-old SSH client.
I can see in the source, some intent to log to Trace, but it is wrapped with a Conditional attribute against the DEBUG flag. I would rather not have to set the DEBUG flag on my Release builds.
In the first instance, since all your Log method appears to do is write to Trace, it would seem more reasonable to have that Conditional attribute check for TRACE rather than DEBUG.
For example, in Session.NET.cs:
```c#
---[Conditional("DEBUG")]
+++[Conditional("TRACE")]
partial void Log(string text)
{
_log.TraceEvent(TraceEventType.Verbose, 1, text);
}
```
However, unless I am missing something really obvious, this becomes a compile-time choice, rather than something an end-user can enable. Often, the requirement to examine these logs is to diagnose a deployed, Release-mode application's failure to access a target server. Changing to a Debug build to do this diagnosis is far from practical.
My own preference is not to hide functionality such as this behind a conditional flag, as it should be something you can enable programmatically (i.e. an option in the implementing application's config file). Therefore, a better option (for me, at least), would be to expose a property which enables logging.
In my own code, I tend to expose a TextWriter-backed property, which defaults to TextWriter.Null, and have my logging implemented as WriteLine calls to that TextWriter -- this would allow the implementor to spit these log messages to a file (via StreamWriter), the console (Console.Out/Console.Error), or an implementation of their choosing.
Another option might be a an event which fires on every log message.
I can see in the source, some intent to log to Trace, but it is wrapped with a Conditional attribute against the DEBUG flag. I would rather not have to set the DEBUG flag on my Release builds.
In the first instance, since all your Log method appears to do is write to Trace, it would seem more reasonable to have that Conditional attribute check for TRACE rather than DEBUG.
For example, in Session.NET.cs:
```c#
---[Conditional("DEBUG")]
+++[Conditional("TRACE")]
partial void Log(string text)
{
_log.TraceEvent(TraceEventType.Verbose, 1, text);
}
```
However, unless I am missing something really obvious, this becomes a compile-time choice, rather than something an end-user can enable. Often, the requirement to examine these logs is to diagnose a deployed, Release-mode application's failure to access a target server. Changing to a Debug build to do this diagnosis is far from practical.
My own preference is not to hide functionality such as this behind a conditional flag, as it should be something you can enable programmatically (i.e. an option in the implementing application's config file). Therefore, a better option (for me, at least), would be to expose a property which enables logging.
In my own code, I tend to expose a TextWriter-backed property, which defaults to TextWriter.Null, and have my logging implemented as WriteLine calls to that TextWriter -- this would allow the implementor to spit these log messages to a file (via StreamWriter), the console (Console.Out/Console.Error), or an implementation of their choosing.
Another option might be a an event which fires on every log message.