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.
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.