Coordinated logging in a SharePoint farm

We are deploying web parts to SharePoint 2007 开发者_运维问答and would like to include logging (log4net). The ideal solution would be to use a database appender to avoid the problems with knowing which actual server is executing the web part.

This questions has been helpful: SharePoint and Log4Net.

I've got log4net working in a stand-alone web app using Visual Studio dev server using the web.config for the log4net settings and a file appender for the output. I'd like to transition to SharePoint and still use the log file output so I can make sure it's all working first, then change the config around to log to a database.

Is this going to be too much trouble? How have other developers added log4.net into their solutions for SharePoint? Is using a database the only good solution to correlating log output to a server?

Update: We have implemented Log4Net and it works to a point. The security model of SharePoint makes configuring the necessary permissions more difficult. In our case we saw that messages would not make it to the log file in certain cases. We used the logging code in a web service that runs as a given account. When we let it run as a dev, e.g. 'us\bob' and that dev uses a page that calls the web service, then the messages make it to the log file. Another unresolved issue is how to take into account the permissions needed for writing to a log directory used by the system, i.e. IIS logs or SharePoint logs.

Switching the configuration to use a database appender is certainly easy. You will need to decide how you want to connect to the database: Integrated Authentication vs. SQL Server Login, but both is easy to configure.

I recommend to deploy log4net as a separate solution since Sharepoint does not track dependencies on assemblies. The same applies for other "core" assemblies that your solutions are going to use. Have a look at this question here.