Tuesday, July 12, 2011

Microsoft Haters vs. Post Sharp

Today at work, I got in a discussion with another developer who "hates Microsoft".  We were talking .NET, and I am a proponent of that technology.  He clearly is not.  For the last few days, I have been working on a project he also works on.  My tasking has included upgrading logging.  Part of that has included going into the code base and putting logging statements at the beginning and, at times, the end of functions.  

Today after work, I went to the monthly meeting of the Huntsville .NET user group (http:.//www.huntug.org).  The presenter was generally talking about Aspect Oriented Programming, and specifically showing the benefits of a single framework:  Post Sharp (http://www.sharpcrafters.com).  The basic pitch is that if you are going to be doing something in a repetitive, predictable way, Post Sharp can automate that for you and clean up your code.    The demo included adding logging capability to an entire .NET assembly by creating a very simple class that overrides two base class methods with one line of code in each override.  The next step was to add a single line of code in an assembly-level file and all functions in the entire assembly now had uniformly-functioning logging on function entry and exit.

Without Post Sharp:

void MyClass::MyMethod()
{
     Trace.WriteLine("Entered MyMethod");
     //Do stuff
     Trace.WriteLine("Exited MyMethod");
}

With Post Sharp:

[Logging()]
void MyClass::MyMethod()
{
     //Do stuff
}

Of course, you also have to write the LoggingAttribute class.  I don't remember the details, and I'm sure this is wrong, but it was something like:

[Serializable]
public class LoggingAttribute : xxxSomePostSharpBaseClass
{
     override SomeEntryFunction()
     {
          Trace.WriteLine("Entered " + args.Functions.Name.ToString());
     }

     override SomeExitFunction()
     {
          Trace.WriteLine("Exited " + args.Functions.Name.ToString());
     }
}

But you only have to write it once, and it can be applied to every function in an assembly, class, or on a function-by-function basis.  Seemed like a nice, useful tool.  

I would have loved it if this developer had come with me, but often we are content to defame something we see as competition rather than spend the time to really consider it an option.  It is our nature - a nature worth fighting.

No comments:

Post a Comment