Hi, thanks this script is quite usefull. Just a question though, what does this do in a multithreaded scenario? I could imagine since SetContext is not thread safe there could be an issue where one thread injects the context into the global Log.Logger and then another thread does a writeline, and gets the wrong data.

Hi, thanks this script is quite usefull. Just a question though, what does this do in a multithreaded scenario? I could imagine since SetContext is not thread safe there could be an issue where one thread injects the context into the global Log.Logger and then another thread does a writeline, and gets the wrong data.

public static void Information(string messageTemplate, [CallerMemberName] string memberName = "",
            [CallerFilePath] string sourceFilePath = "",
            [CallerLineNumber] int sourceLineNumber = 0)
        {
            Serilog.Log.Logger
                .ForContext("MemberName", memberName)
                .ForContext("FilePath", sourceFilePath)
                .ForContext("FileName", System.IO.Path.GetFileNameWithoutExtension(sourceFilePath))
                .ForContext("LineNumber", sourceLineNumber)
                .Information(messageTemplate);

            //SetContext(memberName, sourceFilePath, sourceLineNumber);
            //Serilog.Log.Information(messageTemplate);
        }

Would you think this is more thread safe because it is creating a new logger object rather than putting it in the global Log.Logger field?
I kind of don't want to create a new logger object every time, but i think the logger.ForContext does a good deal of optimizing this. Maybe tomorrow ill run a benchmark - wanting to try a benchmark libray out anyways :)

I didn't test the sample for multi threading safety 😅

Yes technically the ForContext could be called at the wrong time.
Your solution makes it a bit better, but it's still not completely thread safe.

For thread safety, you should use in each "Logging"-method (Info, Debug, Error, etc.) a lock on a static lock-Object.

I updated the the class so that it doesn't use ForContext anymore, because there were problems when a parameter (e.g. MemberName) could get stuck and would be written everytime, when you call Serilog directly on another location.

e.g when calling

public class TestClass
  {
    public void A()
    {
      Log.Info("Some test");
    }
  }

→ 18:16:40,183 INFO TestClass [A] Some test ✔️
and then calling

public class AnotherTestClass
  {
    public void B()
    {
      Serilog.Log.Verbose("Some verbose stuff");
    }
  }

→ 18:16:40,183 Verbose TestClass [A] Some verbose stuff ❌

I didn't test the sample for multi threading safety 😅

Yes technically the ForContext could be called at the wrong time.
Your solution makes it a bit better, but it's still not completely thread safe.

For thread safety, you should use in each "Logging"-method (Info, Debug, Error, etc.) a lock on a static lock-Object.

Well for your 2 remarks (thread saf. and Context getting stuck) you could also create a new logger object everytime like in my sample snippet. This sets the context of a differtent logger object not on the root one - so you should not get any problems if i read the docs right. I have not tested this however and if i get time (which i most likely dont) i will perform a test. I am also curious regarding the performance. Locking would also bring a nasty performance hit, certainly when using async sinks.

I do also like the approach you took right now with just injecting the string. It is however not really configurable this way. Also not compatible with the outputformat of the sinks.

Maybe we can use an enricher or something else in Serilog to get a slightly better/more configurable result?

Hi, thanks this script is quite usefull. Just a question though, what does this do in a multithreaded scenario? I could imagine since SetContext is not thread safe there could be an issue where one thread injects the context into the global Log.Logger and then another thread does a writeline, and gets the wrong data.

public static void Information(string messageTemplate, [CallerMemberName] string memberName = "",
            [CallerFilePath] string sourceFilePath = "",
            [CallerLineNumber] int sourceLineNumber = 0)
        {
            Serilog.Log.Logger
                .ForContext("MemberName", memberName)
                .ForContext("FilePath", sourceFilePath)
                .ForContext("FileName", System.IO.Path.GetFileNameWithoutExtension(sourceFilePath))
                .ForContext("LineNumber", sourceLineNumber)
                .Information(messageTemplate);

            //SetContext(memberName, sourceFilePath, sourceLineNumber);
            //Serilog.Log.Information(messageTemplate);
        }

Would you think this is more thread safe because it is creating a new logger object rather than putting it in the global Log.Logger field?
I kind of don't want to create a new logger object every time, but i think the logger.ForContext does a good deal of optimizing this. Maybe tomorrow ill run a benchmark - wanting to try a benchmark libray out anyways :)

Try using enricher object instead:

InvocationContextEnricher enricher = new InvocationContextEnricher(typeof(T).FullName, callerMemberName, callerFilePath, callerLineNumber);
            return Log.Logger.ForContext(enricher);

Where InvocationContextEnricher is:

public class InvocationContextEnricher : ILogEventEnricher
    {   
        public InvocationContextEnricher(string sourceContext, string callerMemberName, string callerFilePath, int callerLineNumber)
        {
            SourceContext = sourceContext;
            CallerMemberName = callerMemberName;
            CallerFilePath = callerFilePath;
            CallerLineNumber = callerLineNumber;
        }

        public string SourceContext { get; protected set; }
        public string CallerMemberName { get; protected set; }
        public string CallerFilePath { get; protected set; }
        public int CallerLineNumber { get; protected set; }
                
        public static string SourceContextPropertyName {get;} = Constants.SourceContextPropertyName;
        public static string CallerMemberNamePropertyName {get;} = "CallerMemberName";

        public static string CallerFilePathPropertyName {get;} = "CallerFilePath";
        public static string CallerLineNumberPropertyName {get;} = "CallerLineNumber";
        
        public void Enrich(LogEvent logEvent, ILogEventPropertyFactory propertyFactory)
        {
            logEvent.AddPropertyIfAbsent(new LogEventProperty(SourceContextPropertyName, new ScalarValue(SourceContext)));
            logEvent.AddPropertyIfAbsent(new LogEventProperty(CallerMemberNamePropertyName, new ScalarValue(CallerMemberName)));
            logEvent.AddPropertyIfAbsent(new LogEventProperty(CallerFilePathPropertyName, new ScalarValue(CallerFilePath)));
            logEvent.AddPropertyIfAbsent(new LogEventProperty(CallerLineNumberPropertyName, new ScalarValue(CallerLineNumber)));
        }
    }

Awesome work @litetex! Thank you very much!

Hi, is there a running example?

Warning for those coming here!

Serilog works with message templates: message-template-recommendations

And with the above samples, you don't have that message template anymore as you can only pass a single string, which kinda forces you to do string interpolation, which is not recommended.

InvocationContextEnricher enricher = new InvocationContextEnricher(typeof(T).FullName, callerMemberName, callerFilePath, callerLineNumber);
return Log.Logger.ForContext(enricher);

Where to use this one?

And How can this enricher add in serilog?

@akovac35 A piece of the puzzle is missing - how to register the Enricher? It doesnt have an empty constructor

I ended up using a different approach - when creating a custom Enricher, the Enricher-pipeline already have a hook for the "caller class that made the log statement" in the SourceContext property in the LogEvent passed to the custom ILogEventEnricher. Having that information, one can browse through the StackTrace, identify the caller StackFrame by class name and get relevant information.

public class InvocationContextEnricher : ILogEventEnricher
{   
	public void Enrich(LogEvent logEvent, ILogEventPropertyFactory propertyFactory)
	{
		if (logEvent.Properties.ContainsKey(Constants.LogProperties.SourceContext))
		{
			var sourceContext = ((ScalarValue)logEvent.Properties[Constants.LogProperties.SourceContext]).Value?.ToString();
			var callerFrame = GetCallerStackFrame(sourceContext);

			if (callerFrame != null)
			{
				var methodName = callerFrame.GetMethod()?.Name;
				var lineNumber = callerFrame.GetFileLineNumber();
				var fileName = callerFrame?.GetFileName();

				logEvent.AddPropertyIfAbsent(propertyFactory.CreateProperty(Constants.LogProperties.InvocationContextClassName, sourceContext));
				logEvent.AddPropertyIfAbsent(propertyFactory.CreateProperty(Constants.LogProperties.InvocationContextMethodName, methodName));
				logEvent.AddPropertyIfAbsent(propertyFactory.CreateProperty(Constants.LogProperties.InvocationContextFilePath, fileName));
				logEvent.AddPropertyIfAbsent(propertyFactory.CreateProperty(Constants.LogProperties.InvocationContextLineNumber, lineNumber));
			}
		}
	}

	private StackFrame GetCallerStackFrame(string className)
	{
		var trace = new StackTrace(true);
		var frames = trace.GetFrames();

		var callerFrame = frames.FirstOrDefault(f => f.GetMethod()?.DeclaringType?.FullName == className);

		return callerFrame;
	}
}

Nice job @morteng85 ! That works with the message templates! I just needed to implement the Constants, added .Enrich.With<InvocationContextEnricher>() to the LoggerConfiguration instatiation, and the appropriate outputTemplate in my Sink(s), and it all worked! 🙇

How to implement the Constants? Could upload a more complete code please, thank you very much

The solution of @morteng85 uses reflection when calling GetMethod() in the GetCallerStackFrame function, so it is not a real solution for the original question!

@NeverMorewd CreateProperty() methods first parameter is the log property name (or key) and the second is the property value. Eg:
logEvent.AddPropertyIfAbsent(propertyFactory.CreateProperty("my_caller_method_name", methodName));

@marazattila Thanks for your reply.
Eventually I found another similar method: https://gist.github.com/nblumhardt/0e1e22f50fe79de60ad257f77653c813.
It used reflection as well, and I can not find any one without reflection.
My app does not seems to support native aot anymore -_-

And with the above samples, you don't have that message template anymore as you can only pass a single string, which kinda forces you to do string interpolation, which is not recommended.

I was going to say the same thing, message templates should be used. string interpolation in logging is a no no.