Design question regarding logging

Topics: Logging Application Block
Sep 8, 2010 at 11:56 AM
Edited Sep 8, 2010 at 2:52 PM

I have developed a DLL wrapper for the Enterprise Library logging that works well.  It uses an external config file to ensure all logging goes to the same disk based log file.  When more than one process accesses the DLL at the same time I wind up with more than one log file; the first is the named one from the config file, the subsequent ones get GUID based names.  Not completely surprising but not exactly what I want.

I'm thinking that what I want to do is create a singleton WCF service that essentially hosts the same logic as the DLL but will ensure that all logging traffic writes to the same single disk based log file as I intenteded regardless of what process is logging.  Other than managing access to the logging calls, does this approach make sense from a best practices stand point?

 

Sep 8, 2010 at 2:13 PM

EntLib actually ships with the Distributor Service which already does what you want to do.  Check this out from the documentation.

 

Sarah Urmeneta
Global Technology & Solutions
Avande, Inc.
entlib.support@avanade.com

Sep 8, 2010 at 2:54 PM

I am trying to stay away from MSMQ and any thing else that would remind me of COM.

I was thinking that a WCF service was a bit more .NETish and therefore more desirable.

Sep 8, 2010 at 5:13 PM

Ahh, FDD - Fashion Driven Development.

What you're describing is the exact same thing that the existing MSMQ listener already does, the only difference is the transport. And once you wrote your WCF service, you'd still have to decide which binding to use, and one that makes lots of sense is - guess what, MSMQ.

Also, not sure why MSMQ reminds you of COM. That's kind of like saying "I don't want to use TCP/IP, it reminds me of JavaScript."

Anyway, if you've got a strong requirement over code quality or network requirements or something, it makes sense to write a new listener / distributor combo. But I wouldn't do it just because you don't like MSMQ.

 

Sep 10, 2010 at 3:38 PM
Edited Sep 10, 2010 at 6:31 PM

Not quite sure what precipated the poorly veiled personal attacks as I was really just interested in some professional advice, hints, etc.  So perhaps I can try to state my situation a bit better way and perhaps there are some helpful suggestions out there somewhere.

I'm relatively new to the .NET world after spending way too many years wrestling withCOM.  We are currently re-engineering a rather large system a bit at a time due to the fact that we have new feature requirements, support issues, and limited resources.  So I am working on one of the new features and engineering it as a set of new .NET components which will eventually be tied into the existing infrastructure but laying some foundation for the entire system down the road.

The current product has a subsystem that is used to deliver messages to the database for persistance sake, the UI if applicable, and to a disk based file in case of database corruption.  Some of these messages are not necessarily meant for the user but can be viewed and in some cases cause undo alarm.  Some of the more complex subsystems also provide additional debug logging but generally only turned on (usually via a registry key) on an as needed basis.  When started 15 years ago, the project was dealing with much more limited hardware resources which caused us to limit the amount of tracing being performed.

All that aside, as we plan on this new technology platform, we can see a need for a more robust tracing/logging facility (as well as continued message logging to the database, UI, etc.) that will create disk based trace files that will be allowed to grow larger then the current log file, contain information only useful by support/development staff, and provide some level of history as well (rollover files).  Some simple encryption techniques will be used to keep the contents from being viewed by only those needing to see the information.

I was led to the Enterprise Library which certainly seems capable of doing those things which I described above and then some.  I liked the idea of not necessarily having to write from scratch all of the needed functionality and having a sound platform which could be black boxed.  Initially I am only concerned with being able to log activity to a disk file and to the Windows Application Event log.  All this was relatively easy to do and I wrote a DLL wrapper to help standardize the interface and how logging was to be done and what information was to be captured.  Through this same forum I got the advice on how to create and use an external configuration file to ease use and deployment.  All was working well until I started to log from more than 1 process which leads up to my latest posting.

The first process in writes to the named file in the config file, all other processes have a new file created for them with a GUID as their name - not quite what I want or need.  I presume this is done because of file sharing restrictions.  What I had hoped was there was a mechanism internal to the library that would control access to the disk file in this case and it would manage that resource.  Now being new to the Enterprise Library, there may well be some configuration item I am not aware of that would allow this functionality and if so perhaps someone can point that out to me.

Aside from flipping a flag so to speak we must employ another technique to allow all tracing to go to the same file that protects the resource from multiple threads/processes.  My first thought was to provide a WCF service where all the logging information would be filtered through and let the service manage the file resource and we would get everything into the same file.  Presumably, this would be a singleton service hosted in a Windows Service (which has its problems like what happens if that service goes away, etc.)  If I were still in the COM world I would probably develop a singleton DCOM service to meet the need.

Another option as mentioned above involves using other facilities within the Enterprise Library that incorporates MSMQ.  The last I recall of MSMQ is that it is in fact COM based technology (unless something changed very recently)  but also provides a bit more functionality than we need (store and forward, etc.).  We need a light-weight solution that is extensible as we move more of our messaging/logging into it.

Now it may suprise you that I do know the difference between TCP/IP and JavaScript (but just barely).

What I am looking for are possible alternatives to resolving the issue at hand and presume that I have reached a community of professionals that can help me along the way of acclimating to this new .NET world.

Thanks!