There is an option that might work, but it will take some effort on your part to use it.
NLog has the ability to name the log file via most LayoutRenderers. In your case, you could configure your File target something like this:
<target name="FileTarget" xsi:type="File" fileName="${gdc:item=Task}.log" layout=${longdate} | ${logger} | ${level} | ${message}" />
Then, when you are executing a task, you can set the GlobalDiagnosticContext based on your task name:
void processData(String taskName)
{
GlobalDiagnosticContext.Set("Task", taskName);
log.Info("Hello from processData. This should be in {0}.log", taskName);
GlobalDiagnosticContext.Remove("Task");
}
This will cause all log messages that are written to be written to the desired log file.
This might work fine if your application is single threaded, so you don't have to worry about collisions between simultaneous executions of processData.
If you are using threads, you might get good results using the ThreadDiagnosticContext in the same way.
Another idea is to manually create LogEventInfo objects and use the Log method to log them yourself. Something like this:
var LogEventInfo le = new LogEventInfo(LogLevel.Info, logger.Name, "Hello!");
le.Properties["Task"] = taskName;
logger.Log(le);
In this case you would use the EventContext LayoutRenderer to build the log filename:
<target name="FileTarget" xsi:type="File" fileName="${event-context:item=Task}.log" layout=${longdate} | ${logger} | ${level} | ${message}" />
You could wrap the NLog logger or you could write an extension method so that you don't have to deal with building up a LogEventInfo object at every logging site.
For example:
public static class NLogExtensions
{
public static void Log(this Logger logger, string task, LogLevel level, string message)
{
var LogEventInfo le = new LogEventInfo(level, logger.Name, message);
le.Properties["Task"] = task;
logger.Log(typeof(NLogExtensions), le);
}
}
The reason for using the Log signature that takes a Type as the first parameter is to ensure that the logging of call site information work correctly.
See my answer here for a very brief discussion of "wrapping" NLog via an extension method:
Can NLog preserve callsite information through c# extension methods?