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 Jan 26 '14 at 22:58
  • @JTrana Something like a controller? – Reza Owliaei Jan 26 '14 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 Jan 27 '14 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. – Reza Owliaei Jan 27 '14 at 6:32

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 Mar 13 '13 at 15:31
  • No it does not. Check their website, they have a free alternative. – Otávio Décio Mar 13 '13 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 Oct 8 '13 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 Dec 28 '13 at 5:02
  • 2
    @gnat: Please see the update. – Steven Evers Jan 27 '14 at 0:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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