Logging was always a nightmare for me! Now I have to implement it again for a proxy system. In this proxy application, some systems ask proxy system to call some other services. What I have to log is

  • Request Time
  • Requester IP
  • Request Parameters as XML
  • Requested Service Name
  • Requested Service Method
  • Response Time
  • Response data as XML
  • Response Message (If any exception occurs it will logged as Message)

I considered to append two lines to my methods:

// Log Request
Task.Factory.StartNew(() => Logger.Log(RequestParameters.ToXML(),Assembly.GetCallingAssembly().FullName, MethodBase.GetCurrentMethod().Name, DateTime.Now));

// Invoke requested service and get response

// Log Response
Task.Factory.StartNew(() => Logger.Log(Response.ToXML(), DateTime.Now));

I also want to log nested transactions.

Assume a transaction contains a request and a response. A transaction may contains many other internal transactions. When I receive a request, I should register a transaction, and insert a request for it, later, when response received, I should update the transaction response. Please note that I'm trying to store request and response relationship for better tracking.

How can I safely add this logging procedure to methods? I want to restrict developers to implement this logging systems in all methods, some thing like interface or inheritance for method body is required. Can I do this by attributes? Then how?

  • Have you considered making some higher level construct that wraps the logging and request together? Perhaps a wrapper around the requested service? What do the services look like?
    – J Trana
    Commented Jan 26, 2014 at 22:58
  • @JTrana Something like a controller? Commented Jan 26, 2014 at 23:03
  • 1
    Well, I guess when I think a controller I typically think of one thing bundling together a layer of abstraction around a specific service or group of services. Here I think you want to treat this as some sort of a helper function/class that can be parametrized, much like the first answer. If you can make the scope narrow enough, the AOP approach may be overkill - but this is definitely an AOP-esque concept. I think explicitly leaving this as a separate helper will give you better control - this logging sounds heavy so you may turn it off at times. Do services share an interface?
    – J Trana
    Commented Jan 27, 2014 at 1:25
  • @JTrana: You are totally right. Services are from different providers, so there is no shared interface at that level. About AOP, thats right, it's AOP concept with very annoying implementation. Also I cannot make an imagination of a higher abstraction in layer to log very low level and detailed service connectivity data. Commented Jan 27, 2014 at 6:32

2 Answers 2


To restrict developers to use the logging mechanism for anything they want, make its visibility only internal. You can then make it available only to your own projects by adding the InternalsVisibleTo assembly attribute.

To safely and uniformly add the logging mechanism to methods, implement only the functionality in the methods, and wrap the methods in delegates, somewhat like in the following C# like pseudocode:

internal Func<RequestParameters, Response> WrapServiceClientWithLogger(Func<RequestParameters, Response> callService)
    return requestParameters => {
        // Log Request
        Task.Factory.StartNew(() => Logger.Log(requestParameters.ToXML(),
            Assembly.GetCallingAssembly().FullName, GetMethodName(callService), 

        var response = callService(requestParameters);

        // Log Response
        Task.Factory.StartNew(() => Logger.Log(Response.ToXML(), DateTime.Now));
        return response;

This is the hello world scenario for Aspect-Oriented Programming (AOP) and I'm a HUGE fan of it. Your mention/question of using attributes is exactly the implementation detail that is used.

My personal favourite for .NET, though not free (you can roll your own using reflection, and I have, but the performance is comparatively bad) is PostSharp .

Essentially, you have an Attribute that inherits from a PostSharp aspect attribute (eg. OnMethodBoundaryAspect). You would override OnEntry and OnExit to make your async call(s) to trace.

What happens is that PostSharp plugs into compilation and "weaves" the code from your aspect into the IL that gets produced by the compiler, so the performance is roughly identical to what it would be if you had hand-coded it in the method yourself.

Note: I have zero affiliation with postsharp, and have never had the opportunity (ie. budget) to use it in production - sadly. I have used AOP in .NET with success though.

  • PostSHarp works great but costs money.
    – Nahum
    Commented Mar 13, 2013 at 15:31
  • No it does not. Check their website, they have a free alternative. Commented Mar 13, 2013 at 16:53
  • 3
    would you mind explaining more on what it does and why do you recommend it as answering the question asked? "Link-only answers" are not quite welcome at Stack Exchange
    – gnat
    Commented Oct 8, 2013 at 18:21
  • 2
    To all who may be confused: aspect-oriented programming is an interesting approach to handling "cross-cutting" concerns, such as doing something at the start/end of every method. In this case, logging a certain type of message. @A---------------------------- Would you please consider adding some more info to your answer? I think it's a good approach, I just know I would have been very confused before I had been introduced to AOP. Plus, it doesn't make sense for somebody else to repost an answer with the same approach when the points could be yours, right?
    – J Trana
    Commented Dec 28, 2013 at 5:02
  • 2
    @gnat: Please see the update. Commented Jan 27, 2014 at 0:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.