Implement an official FileLogger

[muratg]

A very simple file based logger would be useful.

[grahamehorner]

personally I like the enterprise library semantic logging aka SLAB & feel that should/if this be made coreclr compatible that this would provide a lot of features/benefit for the logging story which could be used by non aspnetcore projects

[davidfowl]

@grahamehorner sure but that has little to do with this issue.

[grahamehorner]

@davidFlow not really given SLAB has many sinks including a simple file and rolling file sink, why reinvent the wheel? also others have asked for EventSource support; killing two birds with one stone. 😀 I've already started a fork of SLAB with a view of making a

[davidfowl]

Because even if slab is ported, we're not going to delete this library. Serilog/NLog/log4Net already has a file logger as well but that won't influence our decision to have a basic file logger out of the box. There's also an event source logger in the works for RTM #424

[Yves57]

• With only one file for all ILogger<> instances, or one file for each ILogger<> (with for instance the logger name as file name)?
• I think that a queue is necessary to buffer the messages (ILogger.Log() is synchronous so it has to be fast). But it is maybe too much for a "basic" file logger?

[davidfowl]

• Single file for all Logger instances that rolls over when it hits a threshold.
• Yes the writing should be buffered and delegated to a worker thread writing to disk.

[victorhurdugaci]

Here's the plan, let me know what you think:

By default:

1. The file logger will log in a predefined location (based on app name) and will number-stamp files. A new log file will be created when the previous log file reaches a certain size. So let's say the size limit is 100mb, then you'll end up with MyApp1.txt (100mb), MyApp2.txt (100mb), MyApp3.txt(42mb)
2. It has a background thread that does the file logging with a queue of a limited size
3. If the queue reaches it's capacity, then the callers will be slowed down

You can configure:

1. The factory that generates the log file name (you could use a time based file name instead for example)
2. The default name factory file size
3. The folder where to logs are store
4. The size of the background queue

Things to consider:

1. What happens when you get slowed down by a full queue. Should we append a message in the log? If yes, how often?

Rough API:

// API:
// Might consider grouping the configuration params in Options

AddFile();
AddFile(folderName = null, queueSize = 100, Func<string, string> nameFactory = defaultnamefactory);

// Examples:

// Default file name, location, queue size, file size
loggerFactory.AddFile(); 

// New naming convention
loggerFactory.AddFile(nameFactory: previousFileName => {
     if (someCondition) {
         return newFileName;
     }
     return previousFileName
});

// Custom folder and log file size (default name)
loggerFactory.AddFile("/someFolder", 1024);

Thoughts?

[cesarblum]

I think the default should be to name log files by date (UTC).