.NET best practice for usage logging - text files? database? [closed]

Question

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.

Closed 9 years ago.

I have a tool that my team uses for various administration tasks, it handles various remote calls, Active Directory look ups, calls scripts and more to support thousands of machines. I have about a dozen people actively using it, but for geekdom and further development I would like to build in some statistic and usage logging (nothing personal, just to see what is used and how much).

My question, is what would be a good (or even best) way in .NET (C# specifically) to log this information?

My first thought was a TXT file or even a XML file, but I don't know that I really want to load a file of unknown size later down the road over and over. So I thought about SQLite, but I do not want to install .SQlite on each machine, although perhaps I can embed it in the exe (Its run from a share, not an install for most users although I also have a setup package built for it.

I really don't want to use lots of text files, just for the sake of clean folders.

Any suggestions that would meet the following criteria:

1. Light weight
2. Fast
3. No installs on the client
4. Stable Hard to corrupt
5. Local Database like

I tried to google this, but I wasn't getting anything that really made sense to me, it was probably that I didn't know what I should Google, as this is not a typical usage model for me.

Answer 1

Microsoft SQL Server Compact is an embeddable, free, redistributable database engine with good APIs for .NET. No install is required; you just make a reference to the database engine library from your .NET project and that's it. Databases are simple files that you can store anywhere and move around like any other.

It is quite similar to the "real" SQL Server, so data migration between the two should be easy in case you need it, and there are plenty of tools to help you with this.

Answer 2

You could use db4o. It is an object-oriented database (no SQL) which saves your objects directly - no need for object mapping, attributes or any configuration overhead, just take your POCOs and save them. You can use different approaches for queries, such as Query by example or SODA (which is similar to criteria for Hibernate), it also has full LINQ-support. You can use db4o as embedded database (uses a file), the memory footprint is very small. No installation required, just include the lib into your project.

Example:

var persons = db.Query<Person>( s => s.Age > 50 );

Answer 3

Use Log4Net and decouple that data sink(s) from your apps. Log4Net lets you log to files, databases, the Windows event log, and others. You can even direct log output to different destinations based on the assembly/class from which it comes, by logging level (Fatal, Error, Warning, Info, etc.) and other filter criteria.

You can even write your own appenders to do just what you need.

All through changing your log4net configuration. You can even adjust the log4net configuration while your app is running. For instance, consider a long-running daemon with logging set to catch fairly high level messages across the app. If you log suddenly starts showing a sudden increase in errors logged, you might want to dial the logging down to a more granular level to get an idea of what's going on. Or perhaps dial it down to a very granular level on the suspect class or assembly to isolate the problem details.

With log4net, you can do that just by tweaking the config file and without bouncing the daemon.