It’s certainly possible. You could use the Action and Func delegates.

TReturn RunWithLog<T, TResult>(ILogger logger, Func<T, TResult> function, T parameter1)
{
    logger.LogInformation(....);
    return function(parameter1);
}

void RunWithLog<T>(ILogger logger, Action<T> function, T parameter1)
{
    logger.LogInformation(....);
    function(parameter1);
}

You’d need to implement one for each number of parameters you want to accept.

You could also return a new func or action that contains the code in those methods to be called repeatedly. But I don’t think there’d be any advantage to doing it that way. I guess you could then pass it as an argument.

Action<T> BuildRunWithLog<T>(ILogger logger, Action<T> function)
{
    return (T parameter1) => 
    {
        logger.LogInformation(....);
        function(parameter1);
    }
 }

Wrote that from memory so syntax may be wrong.

The current answers using a Func or an Action are correctish, but with that approach you will have logging cross-cutting hard-wired into all your classes before invoking the methods.

If you want true AOP or decorators, you probably want to use Type Interceptors. And Castle DynamicProxy. See: https://autofac.readthedocs.io/en/latest/advanced/interceptors.html https://blog.zhaytam.com/2020/08/18/aspnetcore-dynamic-proxies-for-aop/

A dynamic proxy will give you a method like this:

public void Intercept(IInvocation invocation)
{
  _output.Write("Calling method {0} with parameters {1}... ",
    invocation.Method.Name,
    string.Join(", ", invocation.Arguments.Select(a => (a ?? "").ToString()).ToArray()));

  invocation.Proceed();

  _output.WriteLine("Done: result was {0}.", invocation.ReturnValue);
}

Intercept is called before invoking a method, you can do stuff before the method starts, then you call invocation.Proceed(); - that invokes the method, and then you can log the result.

Note that your class methods either need to be virtual, or it needs to have an interface, I’d suggest an interface.

This way you can wire the logging part in through dependency injection in your container, and your classes itself don’t contain logging cross-cutting logic

Logging wise, I’m not sure how familiar you are with dotnet, as you’re saying you’re just starting, I’d suggest inside your classes you stick with Microsoft.Extensions.Logging.Abstractions - so your classes - lets say a class MyService - would be

public class MyService(Microsoft.Extensions.Logging.ILogger<MyService> logger) { }

Then I’d suggest Serilog to use as concrete logger. You’d wire that in with:

     var configuration = new ConfigurationBuilder()
        .SetBasePath(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location)!)
        .AddJsonFile("appsettings.json")
        .Build();

    services.AddLogging(loggingBuilder =>
    {
        var logger = new LoggerConfiguration()
            .ReadFrom.Configuration(configuration)
            .CreateLogger();

        loggingBuilder.AddSerilog(logger, dispose: true);
    });

Sirilog is a very extendable framework that comes with 100s of different Sinks so you can very easily wire in a different output target, or wire in different enrichers without modifying any of your existing code

Not that I would recommend it, but you can also try something like extension methods on Func.

public static RunAndLog(this Func<T> f) {
 LogStart(f);
var x = f();
LogEnd(f);
return x;
}

I think you may have enough diagnostic info with reflection to write something meaningful, and you can add overloads with generic parameters for the func params, and/or Action.

You may also create an IDisposable that logs a start and end statement around a function call:

using var _ = CallLogger(“func name”) {
f();
}

Personally, I wouldn’t do either of these. This level of logging produces an enormous amount of noise, making finding signal very difficult. I would focus more energy on writing unique and helpful messages where they are important, and using git grep to find the related source code when they show up in production logs (assuming you don’t log a stack trace). This level of call logging can be temporarily useful while debugging or reasoning through an app, but rarely belongs in production.

C# does not really implement decorators like that, which can execute autonomously. You would still need to wrap all the functions you want to call.

You can wrap the action using a Func<> or Action, and get the calling member name (e.g. name would be ‘Main’). The Arguments are a pain, as you have to drill down the Expression tree to get them. This case only handles ConstantExpression values, you would also need to handle MemberExpression and probably others.

using System.Linq.Expressions;
using System.Runtime.CompilerServices;

    public static void Main()
    {
        var n = LogWrapper(() => MyMethod("Hello, World!"));
        Console.WriteLine(n);
    }

    private static int MyMethod(string test)
    {
        Console.WriteLine(test);
        return 42;
    }

    private static T LogWrapper(Expression> func, [CallerMemberName] string name = null)
    {
        // Do begin logging
        var body = func.Body as MethodCallExpression;
        var firstArgument = body?.Arguments.First() as ConstantExpression;

        Console.WriteLine("name={0} param={1}", name, firstArgument?.Value);

        var result = func.Compile().Invoke();

        // Do end logging
        Console.WriteLine("end name={0}", name);
        return result;
    }

Hi. Is that Atom/Pulsar?

deleted by creator