Logger in ASP.NET WebSite

Hi, is there any way that I can have a separate console app in my solution that when I run the two projects together (Web + Console) I can send the Lightspeed SQL Dumps to the console app without having to write a load of TCP code or anything like that? Just wondering if there were any classes built in there to handle this sort of thing? Thanks Mike

Hi Mike,

We don't have any built in support for this -- because the console is in a separate process there would need to be some protocol between the ASP.NET and the console processes, e.g. TCP or a named pipe.

One possibility is in your Web project to call Console.SetOut() with a StreamWriter over a named pipe stream.  Then in your console project you could read from this named pipe (in fact you can hook it to the console input and read using Console.ReadLine calls).  This would avoid the need to write your own custom logger to handle the interprocess communication.

Quick sample, ignoring error handling, cleanup. thread safety etc., not fully tested, do not use in production environments, etc.:

// Console app

using (NamedPipeServerStream stm = new NamedPipeServerStream("WonderPipe"))
{
  stm.WaitForConnection();
  Console.WriteLine("Connected");

  Console.SetIn(new StreamReader(stm));

  while (stm.IsConnected)
  {
    Console.WriteLine(Console.ReadLine());
  }
}

// Web project, probably in Global.asax.cs

private static StreamWriter _logWriter;

protected void Application_BeginRequest(...)
{
  if (_logWriter == null)
  {
    NamedPipeClientStream stm = new NamedPipeClientStream("WonderPipe");
    stm.Connect();
    Console.SetOut(new StreamWriter(stm));
  }
}

Oops, that Application_BeginRequest handler should read:

if (_logWriter == null)
{
  NamedPipeClientStream stm = new NamedPipeClientStream("WonderPipe");
  stm.Connect();
  _logWriter = new StreamWriter(stm);
}
Console.SetOut(_logWriter);

Sorry about that.

And one more bit (sorry):

In Application_EndRequest, you will need to flush the stream: Console.Out.Flush().  (You might need to flush the underlying NamedPipeClientStream as well.)

Hi Ivan,thanks for this, it's great, exactly what I was looking for. I've decided to wrap it into a Logger class so its out the way but I have one question. Would it be possible to make the Logger object as disposable in the future so we can do a bit of cleanup in there? I'm thinking of making a more robust version of this in the future at some point, maybe a client app that could be used to connect to a prod server and see whats going on if there are any problems and it would be nice to have the ability to do some standard cleanup in the logger without having to add extra bits in the host code? Or maybe there is a way of doing this already that I've missed?

We don't want to require loggers to implement IDisposable, because logging is typically set up in configuration and the logger remains in place for the lifetime of the application, so eager freeing of resources isn't usually important.  For example, if the named pipe example, you might implement your custom logger to keep the named pipe around always, but write to it only if it connected.  (You'll want to do some decent stress testing if you plan to use this in a production environment because of things like buffers filling up, multithreaded usage, etc.)

But there's nothing to stop you marking your custom logger class as IDisposable, and disposing of it directly when you decide it's no longer needed.  (That would have to be done in your code because we can't know when the logger is no longer required.)  If you don't want your cleanup logic to depend on the particular logger in use then you can still write something like:

IDisposable disposable = context.Logger as IDisposable;
if (disposable != null)
  disposable.Dispose();

As a final note, if you are thinking about a logger for general production diagnostic purposes then I would encourage you to consider using log files rather than a console live view, so you can look back in time and see what happened leading up to the failure.  You can approximate a live view off a log file by using the tail command.  Of course this is a broader issue and a diagnostic logger will want to pick up much more stuff than just the LightSpeed generated SQL!  Hooking a live view up to the LightSpeed logger is more handy as a way of interactively running tests if there is a specific problem with LightSpeed or the database.

Only 6 years later, the thread continues...

I did this:

public class IntegratedLogger : Mindscape.LightSpeed.Logging.ILogger {

    private void LogToApplicationLog(string text)
    {

        // passes text to whatever logging service or platform the application uses
        **Global.log.Debug(text);**

    }
    public void LogSql(object sql)
    {
        LogToApplicationLog(sql.ToString());
    }
    public void LogDebug(object text)
    {
        LogToApplicationLog(text.ToString());
    }

}

which forced the IntegratedLogger to use the Mindscape verseion of ILogger, while it called a log4net logger that also implements ILogger inside (although I am not sure at that point that it matters any more..)

It is odd that this thread is marked as antique considering I posted this reply today.... but it looks like ALL the posts here are antiques. Odd. Very odd. Is this ORM software being used by anybody at present or am I the only person in the world that has questions about it?

Plenty of folks are using LightSpeed :-) One of the product team will follow up later as needed.

I wrote the forum software years ago and would have just used the thread CreatedOn property for showing the old content warning. If you just browse from the normal list of threads (excluding the one you've just posted on, bringing it to the top) they're not antique threads.

We evolved the API a lot more in the early days so oftentimes if somebody read a thread that was more than a 6-12 months old the information could be out of date. The API in LightSpeed is far more stable these days so it's less of an issue.

I hope that helps explain why the thread is still being marked as old. I should have just made it so you can't post on a very old thread in retrospect!

John-Daniel Trask

Thank you John-Daniel. I certainly was confused by the evident popularity of the software and the forum's old posts.

You can save my life and possibly my marriage if you can solve the riddle of one-to-one associations with a full example at your earliest convenience. It is tantalizingly close but I am still getting this circular association problem. It is Oracle. I must supply the string primary keys - don't ask.