>Since I am seperating all the code for this specific component to be used in multiple applications I would not have access to log exceptions from this component to the same log file. I could include the logger in the component and have a component specific log file but not sure if that would be all that helpful. My question is what do others do when they write a library with a public interface only to be used as a component in another application. Exceptions that I catch are the only thing that I am thinking of in this case. Do most just catch them and try to recover and not worry about logging them? I could raise a component error event so the application can worry about it. That seems reasonable. Any thoughts appreciated.
>Tim
That's how I generally handle it - the exceptions I can catch/handle/recover from in my code, I go ahead and do that. All others I just let the exception occur and leave it to the calling application to handle (or more usually) just log.
There are a few cases where I might be tempted to bake-in logging into a component that I'm using in multiple apps. is when this component does some complex function and I really want to be able to debug issues in production, be able to turn on additional messaging to determine if it's functioning properly while attempting to track down issues, etc.
It would seem like in either case, your logging component should be able to figure out the .config file for the app. and look for the specific location of where it should log messages. Then you could have logging all occur within the same location and not end up with two different log files.
BTW - take a look at the open source Log4Net project.
http://logging.apache.org/log4net/index.htmlThe config files are a little weird (there are a bunch of variations, so it can be a little work to figure out the exact settings). However, it gives you the ability to log to a file, the event log, SQL Server, a text file, send an e-mail, include different messaging types (so you can turn on "full" logging during development and then switch to error logging only for production via the .config file), in almost any combination of all of the above.
