Where to write log for Windows app

Question

I've got a .NET Windows application that's deployed via ClickOnce to a Web server. There are approximately 100 users at any given time, all centrally located. I'm using log4net to log within the application, but I'm having trouble arriving at the best place to put the log.

I've tried having them write to a shared network location, but some users have experienced poor I/O with that approach. I've tried logging to the user's temp folder, but that makes it harder to retrieve the logs. I haven't tried the event log because I will probably have to jump through some hoops to get that working, and I'm not sure if it's worth it. I've never tried database logging, but I've always assumed that it would be relatively slow.

Does anybody have experience with logging in a Windows application deployed in a corporate environment? Any suggestions on where I can put the log so that it will be (1) quick, (2) reliable, and (3) accessible?

Answer 1

The problem with Database logging isn't the speed: it's the reliability. You log for when things go wrong, and if something's going wrong already the odds of an inaccessible DB aren't in your favor.

Generally, you want to write to a local text file and somewhere else like a network share or DB. If you're having IO/speed problems you can use the text file as a buffer and write logs to the contended resource in batches. Then you periodically flush the local 'backup' logs.

Answer 2

What about the ApplicationData folder? On Vista that would be something like this:

C:\Users\Ray\AppData\Local\MyCompanyName

If you want a central location I would go with the database logging. But as Joel said, you'll want both a local location that always works (or as close to it) and a central place to collect logs for when things are working normally.

Answer 3

If the app is a typical two-tier job, logging to the database with AdoNetAppender is probably appropriate. AdoNetAppender batches up log messages in chunks of up to 100, though you'll probably want to configure it to write through on at least WARN severity events.

You may also want to consider logging to the All Users Application Data directory, although this may make it equally unwieldy to retrieve logs. Perhaps consider adding a shortcut somewhere?

Finally, if log accessibility issues are a common theme in your organization, you may want to consider a log collection app such as Splunk.

Answer 4

log4net supports database appenders for some major databases. This might be a better alternative if you have a suitable database available. Approach with caution, however, because it could reduce the reliability of your application if not managed correctly.

You could use it in conjunction with local file logging by using a BufferingForwardingAppender to batch your network logging and send only when you get a message that exceeds a certain threshold. That way, you can have sufficient context to trace errors, but only when errors occur.

<appender name="BufferingForwardingAppender" type="log4net.Appender.BufferingForwardingAppender">
<bufferSize value="1024" />
<lossy value="true" />
<evaluator type="log4net.Core.LevelEvaluator">
  <threshold value="ERROR"/>
</evaluator>
<appender-ref ref="DatabaseAppender" />

Answer 5

You could try somewhere under the CommonAppData folder - i.e., CommonAppData\YourAppName\Logs - provided that you ensure size limits and/or periodic cleanups. People are used to periodically clean up the temp folders but are wary of starting ot dig around CommonAppData, AppData or LocalAppData.

Writing anywhere else but here or into Temp will sooner or later get you in trouble on Vista and higher.

If the logs are not vital, i.e. if irreplaceable data won't get lost if someone deletes the log, I would definitely go for a subfolder in Temp and have a separate task scheduler job upload them. It's the least painful place.

Answer 6

I've used log4net with ms sql databases. I generally put them a dedicated db, on a different server, if possible. That way if there are problems with the application server or db, I don't lose my logging.

Speed was never an issue.

Answer 7

You could use a combination of local logging, and you could sync the logs to a centeral database at successful log off.

It depends on what kind of logging you want to do and how your application is running. If the application doing the logging is a client side application, then if you write to the event logs it may not be helpful.

If you do want to write to the event logs, it's fairly straight forward:

http://support.microsoft.com/kb/307024

One more thing, if you are looking for a location that you know the user has access to for sure, you can use isolated storage, but the fact that you were trying to write to a shared folder makes me thing that you want one central location for your logs, in which case a DB is probably your best bet, and my top suggestion may be best for you.

Answer 8

In our applications we log4net and use a common log file for all our users, in the CommonAppData directory (C:\Documents and Settings\All Users\Application Data\Company\Product). In this case our installer has to manually set the file permissions for the directory and log file so all users can access it, the default permissions are only for the user that installs the application.

We also log unhandled exceptions (when we can) to the event log using a top-level exception handler (using an implementation similar to: http://www.wintellect.com/cs/blogs/jclark/archive/2005/03/30/simple-main.aspx). We use the event log since all bets are off about the state of the file streams that are opened. Again, our installer has to set up the event log source in the Application event log.

If you do use the event log, make sure your logging is pretty minimal. If you log a lot of events since the event log can get filled up pretty quickly, and the default policy on XP is for the event log to start dropping events if the log is full, and the default size is relatively small (512 KB, and only overwrite events older than 7 days).