I want to show you something that many of you may be familiar with since it’s really not new to .NET 4 (well not all of it anyway).  Be that as it may, I think it falls into the category of “still not too regularly used”.  The technique I’m going to show you has to do with Lambda expressions in my examples but can certainly be accomplished with anonymous delegates.

I’m not here to show you an intro to Lambda expressions, but instead how to mix them with the Action<T> and Func<T> delegates for some cool coding techniques.  But first, an introduction to these delegates:

The oldest and simplest is Action<T>.  This delegate was introduced back in .NET 2.0 and could be used with anonymous delegates.  The signature of this delegate is:

public delegate void Action<T>(T arg);

With this pretty free-form signature, the delegate is pretty useful in any scenario where you need to define methods with single signatures.  Later after my introduction, I’ll show you how to use this delegate in a cool technique.  Now, in .NET 4 Microsoft proved that their developers watch entirely too much Mythbusters, by falling into the creed of “What’s worth doing, is worth over-doing”.  I’m not being critical here; I fall into that one all the time myself.  In .NET 4, Microsoft expanded on the Action<T> idea and came out with Action<T1, T2>.  How’s that overdoing it you ask?  Well gentle reader, that’s not the overdoing part, this is: Action<T1, T2, T3>, Action<T1, T2, T3>, and Action<T1, T2, T3, T4>.  If you still think that’s not too much, it actually goes out to T8.

The signatures of these delegates are as you may guess, the same as the original but with additional arguments.  For example:

public delegate void Action<T1, T2, T3>(T1 arg1, T2 arg2, T3 arg3);

I guess you can call this a “one size fits all” delegate.

Also in .NET 4 came the introduction of the Func<TResult> delegate.  The signature of this delegate looks like this:

public delegate TResult Func<TResult>();

There’s also one that accepts a single argument called, Func<T, TResult>, whose signature looks as follows:

public delegate TResult Func<T, TResult>(T arg);

And as you can guess, there are others.  Specifically, Func<T1, T2, TResult> and so on all the way to T8 as well.

From what you can see here, the difference between the two delegates is that Action does not offer a return type and Fun does.  So what’s this good for?  Let me show you.

I’ll start with the Action delegate since its lack of return type make for a bit simpler example.  The Action delegate lets you assign a piece of code to a variable for later invocation.  The type(s) defined in the generic determine the types of the arguments you use in either an anonymous delegate or a lambda expression.  For my examples, I’m going to use lambda expressions and keep things current.  Check out this code sample:

Action<IProcessable> process = (processable =>
{
    processable.PerformSomethingHere();
    foreach (var item in processable.SubItemList)
    {
        item.DoSomethingWithItem();
    }
});

This code is designed to act upon any object that implements the IProcessable interface.  It simply calls a method defined by that interface then looks through a list property called SubItemList, which is also defined in the interface.  On each item in the list, it calls a method on that item.  This idea will be very similar to simply putting this code in its own method, then calling that method with any implementation of IProcessable.  However, if you have no need to use this code from multiple outside methods, yet still have to call it multiple times (as you’ll see in a second), defining it this way makes for great encapsulation and isolation.  So not let’s say I have an object hierarchy that looks something like this:

Parent.Children[x].GrandChildren

In other words, the Parent object has a collection of Child objects in a property called Children, and each child object has a collection of GrandChild objects in a property called GrandChildren.  The Parent, Child, and GrandChild classes all implement the IProcessable interface so I need to execute the code snippet you saw above on all these objects.  As I said, it’s easy enough to put the above-code in a method and just called that method from a for-each scenario on my Parent object, but I won’t need that code called from anywhere else and I want to keep all this encapsulated in my one method. I can use the processable variable and invoke it, sending into its argument any instance of the IProcessable interface.  The solutions is to do something like this:

Action<IProcessable> process = (processable =>
{
    processable.PerformSomethingHere();
    foreach (var item in processable.SubItemList)
    {
        item.DoSomethingWithItem();
    }
});

process.Invoke(Parent);

foreach(var child in Parent.Children)
{
    proces.Invoke(child);
    foreach (var grandChild in child.GrandChildren)
        process.Invoke(grandChild);
}

As you can see, the solution is simple and elegant and eliminates the need to have yet another method in your class.  If I wanted to pass in another value, like a boolean, into each invocation of the code snippet, I can use the Action<T1, T2> delegate.  the lambda expression would then have two variables in it.  Here’s the same code modified I the way I’ve just described:

Action<IProcessable, boolean> process = ((processable, b) =>
{
    processable.PerformSomethingHere();
    foreach (var item in processable.SubItemList)
    {
        item.DoSomethingWithItem();
        item.BooleanPropertu = b;
    }
});

process.Invoke(Parent, false);

foreach(var child in Parent.Children)
{
    proces.Invoke(child, true);
    foreach (var grandChild in child.GrandChildren)
        process.Invoke(grandChild, true);
}

It’s very important to wrap the two arguments prior to the lambda’s “goes to” operator using parentheses.  Pretty cool huh?  Yeah, I think so too .  Let’s take a look at using the Func delegate in a very similar fashion.  Remember, this delegate defines a return type as well.

The usage scenario for this delegate would be pretty much identical as the previous, only you would have the need to return a value from the invocation.  So this time, let me share with you a real-world example on where I’m currently using this delegate.  First let me set the scene.

I have a situation where I have to obtain three different database schema query filters (strings) from an incoming dictionary of key-value pairs (IDictionary<string, string>).  The dictionary comes into a method and potentially contains three items keyed by “TableFilter”, “CommandFilter” and “ViewFilter”.  I say potentially because the incoming dictionary may not contain all of these keys, or none at all, but those that are present contain values that are needed in individual variables.  So for example, under normal, boring code circumstances, I would need to check the incoming dictionary (a variable called arguments) to see if it contains the key TableFilter.  If it does, I set its value in a string variable called stringFilter.  I need to repeat this for the other two keys I’m looking for.  Oh, and did I mention that the arguments variable can come into my method as null as well?  And, if either the key is not found in the dictionary or the entire dictionary comes in as null, I still need my string variable(s) but with an empty string as their value.

Fine, you’re thinking I can simply check arguments for null first, then do a “contains” check on each key and then set each variable accordingly.  Man would that be boring!  Let’s do it in a much cooler way:

Func<string, string> filterCheckAndSet = (key => 
{
    string filter = "";
    if (arguments != null && arguments.ContainsKey(key))
        filter = arguments[key];

    return filter;
});

string tableFilter = filterCheckAndSet.Invoke("TableFilter");
string commandFilter = filterCheckAndSet.Invoke("CommandFilter");
string viewFilter = filterCheckAndSet.Invoke("ViewFilter");

Here, you can see I’m defining my code snippet in a Func<T, TResult> delegate type, where the first generic defines what I’m sending into the code and the second defines what I’m returning.  As you can see, I default my return-type to an empty string, I check the dictionary against it being null and also containing the key I need.  The key is one of the arguments I will send into the piece of code.  If I find the key, I set the my return variable to the contents of that dictionary item and then return it; yes I can do a return inside code defined in a Func delegate type.  Later, I simply invoke the filterCheckAndSet variable, sending in each key, and using the return value in each string variable I need.

That’s it.  I’ve found myself using these techniques more and more.  But remember, the biggest argument you’ll find against this is that you can accomplish the same with additional method calls.  My argument is, yes you can, but if you don’t need a specific level of code re-use, try to limit the scope of the code as it provides better encapsulation.  Also, remember that the code snippets are stored in object variables so they can be passed around anywhere you want (should you actually have that particular need).

Until next time…

My last posting demonstrating what I thought was a pretty cool technique for intercepting WCF operation calls so you can report them on a console; that is when you host on a console application for development.  Looking back at that technique, however useful to me, there was something that bugged me.  The behaviors I showed you how to write had the reporting-to-the-console part built right into them, and I wasn’t exactly satisfied that.  I still maintain the usefulness of reporting every operation call to my host console but wouldn’t it be a more powerful technique to report every operation call and allow the actual host application to do the reporting?  That way, whenever you finally deploy you services, you can track operation calls with any hosting application and do whatever you want with them.  In the case of a dev-console host, I can still report the calls to the console, but in the case of an IIS or NT-Service deployment I can chose to log them somewhere, even a custom event log.

So building on the same technique and code from the previous post, I changed the parameter inspector to raise an event instead of accessing the console.  Since the operation behavior is what instantiated and installed the parameter inspector, its job is to bubble the event up through another event.  In turn, the service behavior instantiated and installed the operation behavior on every operation so it also takes the information from the captured event and raises its own event.  Finally, the console host (in my case), which instantiates and installs the service behavior, captures its event and reports to the console.  The end-result in my case is the same, but the ability to simply capture an event from my hosting application gives me the ability to do whatever I want with the information.  Remember, each class raises an event to its parent which in turn raises its own event all the way up to the actual host.

If you haven’t read my last blog posting, I strongly suggest you go back and read it because I will not be re-explaining the details of the inspector and behavior classes, nor their installation details in this posting.

The first I thing I did was create an event argument class called OperationInformationEventArgs which contains all the information about an operation that I want to send up the chain.  This class is used by all three of the other classes, the parameter inspector, the operation behavior, and the service behavior.

Here is the code for the event argument class:

public class OperationInformationEventArgs : EventArgs
{
    public OperationInformationEventArgs(string serviceName, string operationName, DateTime timeStamp)
    {
        ServiceName = serviceName;
        OperationName = operationName;
        TimeStamp = timeStamp;
    }

    public string ServiceName { get; set; }
    public string OperationName { get; set; }
    public DateTime TimeStamp { get; set; }
}

Next, I renamed the two behavior classes and the parameter inspector so their names were more general and did not imply console-reporting.  I called them OperationReportInspector, OperationReportOperationBehavior, and OperationReportServiceBehavior.  Also notice that I removed the word Attribute from their class name because I decided to no longer make them attribute capable.  Since I’m going to need to do some event wiring, using them in an attribute context would not have worked.

The parameter inspector class now takes the information that it was previously reporting directly to the console, and instead sticks it in the event argument and raises an event.

Here is the code for the new parameter inspector class:

public class OperationReportInspector : IParameterInspector
{
    public OperationReportInspector(string serviceName)
    {
        _ServiceName = serviceName;
    }

    public event EventHandler<OperationInformationEventArgs> ServiceOperationCalled;

    protected virtual void OnServiceOperationCalled(OperationInformationEventArgs e)
    {
        if (ServiceOperationCalled != null)
            ServiceOperationCalled(this, e);
    }

    string _ServiceName = string.Empty;

    void IParameterInspector.AfterCall(string operationName, object[] outputs, object returnValue, object correlationState)
    {
    }

    object IParameterInspector.BeforeCall(string operationName, object[] inputs)
    {
        //Console.WriteLine(string.Format("{0} - '{1}.{2}' operation called.", DateTime.Now.ToLongTimeString(), _ServiceName, operationName));
        OnServiceOperationCalled(new OperationInformationEventArgs(_ServiceName, operationName, DateTime.Now));

        return null;
    }
}

For comparison purposes, I left the old line that wrote out to the console in there and commented it out so you can see the difference.

Now I modified the operation behavior that would install the parameter inspector so just after it instantiates, it wires into the ServiceOperationCalled event.  This class also raises an event with the same information (with the same event arguments class in fact) in the method wired to the parameter inspector’s event.

Here is the code for the new operation behavior class:

public class OperationReportOperationBehavior : IOperationBehavior
{
    public event EventHandler<OperationInformationEventArgs> ServiceOperationCalled;

    protected virtual void OnServiceOperationCalled(OperationInformationEventArgs e)
    {
        if (ServiceOperationCalled != null)
            ServiceOperationCalled(this, e);
    }

    void IOperationBehavior.AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)
    {
    }

    void IOperationBehavior.ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
    {
    }

    void IOperationBehavior.ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
    {
        string serviceName = dispatchOperation.Parent.Type.Name;
        OperationReportInspector inspector = new OperationReportInspector(serviceName);
        inspector.ServiceOperationCalled += inspector_ServiceOperationCalled;

        dispatchOperation.ParameterInspectors.Add(inspector);
    }

    void IOperationBehavior.Validate(OperationDescription operationDescription)
    {
    }

    void inspector_ServiceOperationCalled(object sender, OperationInformationEventArgs e)
    {
        OnServiceOperationCalled(e);
    }
}

Finally, I modified the service behavior class so just after it instantiates the operation behavior, it wires its event to a method where its own event is raised; again with the same event argument information.

Here is the code for the new service behavior class:

public class OperationReportServiceBehavior : IServiceBehavior
{
    public event EventHandler<OperationInformationEventArgs> ServiceOperationCalled;

    protected virtual void OnServiceOperationCalled(OperationInformationEventArgs e)
    {
        if (ServiceOperationCalled != null)
            ServiceOperationCalled(this, e);
    }
        
    void IServiceBehavior.AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters)
    {
    }

    void IServiceBehavior.ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
        foreach (ServiceEndpoint endpoint in serviceDescription.Endpoints)
            foreach (OperationDescription operation in endpoint.Contract.Operations)
            {
                OperationReportOperationBehavior behavior = new OperationReportOperationBehavior();
                behavior.ServiceOperationCalled += behavior_ServiceOperationCalled;

                operation.Behaviors.Add(behavior);
            }
    }

    void IServiceBehavior.Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
    }

    void behavior_ServiceOperationCalled(object sender, OperationInformationEventArgs e)
    {
        OnServiceOperationCalled(e);
    }
}

So now, all that is left to do is to change the actual console host application so when it instantiates and installs the service behavior, it wires into its ServiceOperationCalled event, then displays the information to the console using the wired method.

Here’s the new code for the console host:

OperationReportServiceBehavior behavior = serviceHost.Host.Description.Behaviors.Find<OperationReportServiceBehavior>();

if (behavior == null)
{
    behavior = new OperationReportServiceBehavior();
     behavior.ServiceOperationCalled += behavior_ServiceOperationCalled;

     serviceHost.Host.Description.Behaviors.Add(behavior);
}

void behavior_ServiceOperationCalled(object sender, OperationInformationEventArgs e)
{
    Console.WriteLine(string.Format("{0} - '{1}.{2}' operation called.",
        e.TimeStamp.ToLongTimeString(), e.ServiceName, e.OperationName));
}

As I said, the end-result is the same as in my previous posting but now the hosting application can chose to do what it wants with the contents of the event argument.  In my humble opinion, what was a cool technique is now a cooler technique.

Until next time…

Note: Using a Console app for hosting should be done for development only !

Now that the disclaimer is out of the way, I currently doing some development work for a customer and I had the need to know every time any of my services receives a call.  Since I do my development using a console application for service hosting, it was easy enough to write out to the console from each service operation.  Of course, putting code in every method was possible but not only would it be time consuming, to turn it off later would be a pain.  The answer needed to be something that gets hit on every operation.  Since WCF is essentially one giant inversion of control container, I knew there was a point I could tap into before any operation call.

Enter behaviors !

This turned out to be a multi-step process but once it’s in my library of WCF stuff, I can reuse it and it actually turned out to be quite cool.  I’ll explain each step and the reasons for the step.

Step 1 – Write a custom Parameter Inspector

The first class you need to write is one that implements the IParameterInspector which is in the System.ServiceModel.Dispatcher namespace.  This class will later be installed in such a way that it gets hit on every operation call.  The operation name is one of the arguments you have access to, as well as all the operation arguments which I don’t need in this case.

The methods in this implementation are BeforeCall and AfterCall, and it is the BeforeCall that I’m interested in.  The code I’ll place in this method very simply outputs something out to the console using Console.Writeline.

Unfortunately the name of the service is not passed into this method so I need to get that into this class using a custom constructor; you’ll see how I’ll get it to the class later.

Here’s the code for my ConsoleReportInspector class:

public class ConsoleReportInspector : IParameterInspector
{
    public ConsoleReportInspector(string serviceName)
    {
        _ServiceName = serviceName;
    }

    string _ServiceName = string.Empty;

    void IParameterInspector.AfterCall(string operationName, object[] outputs, object returnValue, object correlationState)
    {
    }

    object IParameterInspector.BeforeCall(string operationName, object[] inputs)
    {
        Console.WriteLine(string.Format("{0} - '{1}.{2}' operation called.", DateTime.Now.ToLongTimeString(), _ServiceName, operationName));

        return null;
    }
}

Step 2 – Install the class using an Operation Behavior

In order to install the parameter inspector, I’ll need to write a custom operation behavior class.  This is a class that implements the IOperationBehavior interface.  You need to remove the throw to NotImplementedException from all the methods; and the method of concern here is ApplyDispatchBehavior.

The name of the service being called is accessible through the Parent property of the dispatchOperation argument.  I need to instantiate my ConsoleReportInspector class and send the service name into the constructor I added earlier.  Afterward, I just need to add my parameter inspector class to the list of parameter inspectors accessible in this behavior.

I also inherited this class from the System.Attribute class so I can use it as an operation behavior attribute on individual operations if I wanted.  This is just for flexibility since I plan on hooking this into a service so it affects all operations.

Here’s the code for my ConsoleReportOperationBehaviorAttribute class:

[AttributeUsage(AttributeTargets.Method)]
public class ConsoleReportOperationBehaviorAttribute : Attribute, IOperationBehavior
{
    void IOperationBehavior.AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)
    {
    }

    void IOperationBehavior.ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
    {
    }

    void IOperationBehavior.ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
    {
        string serviceName = dispatchOperation.Parent.Type.Name;
        dispatchOperation.ParameterInspectors.Add(new ConsoleReportInspector(serviceName));
    }

    void IOperationBehavior.Validate(OperationDescription operationDescription)
    {
    }
}

As-is, I can simply decorate a service operation with [ConsoleReportOperationBehavior] and if hosted on a console application, you’ll see output to the console when the decorated operation is called.

Step 3 – Install the operation behavior on all operations using a Service Behavior

Next I need to write a service behavior.  This is a behavior that gets installed when the service loads (the host is opened).  The job of this behavior is to install my operation behavior on all the service operations.  A service behavior is a class that implement the IServiceBehavior interface.  Like before, I’ll remove the exception calls and once again the method I’m interested in is ApplyDispatchBehavior.

I’m going to iterate through all the endpoints of this service, which are accessible through the serviceDescription argument, and for each endpoint I will iterate through the operations of the contract of each endpoint.  To each operation I will add an instance of my ConsoleReportOperationBehaviorAttribute class.

This class too I will inherit from Attribute so I can use it to decorate a service in the case that I wanted to take this approach at some time. 

Here’s the code for my ConsoleReportServiceBehaviorAttribute class:

[AttributeUsage(AttributeTargets.Class)]
public class ConsoleReportServiceBehaviorAttribute : Attribute, IServiceBehavior
{
    void IServiceBehavior.AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters)
    {
    }

    void IServiceBehavior.ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
        foreach (ServiceEndpoint endpoint in serviceDescription.Endpoints)
            foreach (OperationDescription operation in endpoint.Contract.Operations)
                operation.Behaviors.Add(new ConsoleReportOperationBehaviorAttribute());
    }

    void IServiceBehavior.Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
    }
}

Step 4 – Apply the service behavior to any service I want programmatically at the host

Whatever approach you take to hosting, all you need to do is access each instance of ServiceHost and add the service behavior to the list of behaviors in the host.  I have my own techniques for hosting which include some custom declarative stuff to allow me to turn hosting on and off at will through config.  I also like to separate the accumulation of my ServiceHost instances from the actual application that will do the hosting.  This way I can move it to a Windows Service when I’m ready to go to production.

Here’s the code that installs the behavior:

ConsoleReportServiceBehaviorAttribute behavior = serviceHost.Host.Description.Behaviors.Find<ConsoleReportServiceBehaviorAttribute>();
if (behavior == null)
    host.Description.Behaviors.Add(new ConsoleReportServiceBehaviorAttribute());

The host variable is an instance of ServiceHost.  I perform the code above in between a config check so I can toggle it off at will.

The end result is quite cool since when turned on, every call to any of your services will be shown on the console.

Until next time…

The following text was originall written by Rachel Appel, Developer Evangelist for the NY region:

On July 7th, 2010 at 7pm in Manhattan the NYC area developer community will be holding an event to benefit NYC-area .NET software developer Wendy Friedlander.

Wendy is a 30 year old software agilista from Long Island. She's a strong WPF developer and a firm believer in the agile method of development including pair programming and TDD. Wendy is wife and mother of a beautiful girl named Kaylee who will be 2 in August of this year. In August of 2009 Wendy learned that she had a rare and aggressive pediatric cancer called aveolar rhabdomyosarcoma. Her treatment consists of high dose chemotherapy and radiation. She has had to leave her job, and her husband has been forced into part time work in order to care for their daughter.
Come and be part of something special!

We are very pleased to be able to announce that the evening will include a unique presentation by noted .NET luminary and author Charles Petzold on an obscure (but interesting) chapter in the history of computing with appearances (in chronological order) by Cicero, Galileo, Kepler, Newton, Fourier, Charles Darwin, Lord Kelvin, Madame Curie, and Albert Einstein.

In addition, Miguel Castro has volunteered to provide a very special talk for the attendees where he promises to demonstrate some of his own pet software development projects for us!

In addition to the opportunity to see these unique talks, every attendee will be given a free unlimited 30-day subscription to TekPub (http://www.tekpub.com), the video screencasting site with hours and hours of screencasts on topics including Silverlight, Entity Framework, NHibernate, JQuery, Ruby-on-Rails, developing for the iPhone, and developing for Android. Everyone who attends the event is guaranteed this free subscription just for their cost of attending.

Other SWAG that will be raffled off to attendees includes multiple software licenses for the following products:
* JetBrains Resharper, DotTrace, and DotCover!
* Developer Express CodeRush, Refactor! Pro, and DXperience Suite (every control they make!)
* Telerik RAD Controls!
* TypeMock Isolator!
* Visual Studio MSDN Ultimate i-year Subscriptions!
* ...and more!

Specific details for this event including location, RSVP links, and more can be found at the site:
http://www.DevsForWendy.com

For more details about the event, please see this comprehensive blog post by Steve Bohlen:
http://unhandled-exceptions.com/blog/index.php/2010/06/30/devsforwendy/

Attendance is $75 per person with all proceeds going to Wendy and her family. Since dinner will consist of pizza and soda, you can be assured that more than $65 of that attendance fee will go to benefit the Friedlanders directly!

Even if you cannot attend the benefit event itself, please consider using the [Donate] link on the site (http://devsforwendy.com/donate.html) to make a contribution directly to Wendy and her family. Any amount you may be able to spare would be very much appreciated -- whether $1, $5, $10, $50, or more it all adds up and it all goes to a great cause!

If there are any questions, please do not hesitate to email either Sara Chipps (sarajchipps@gmail.com) or Steve Bohlen (sbohlen@gmail.com) directly.
Otherwise, please consider either attending the event, making a direct donation, or both!

Wow, what a day!

The first ever WCF Firestarter event was yesterday at the New York City Microsoft offices and it was awesome.  The agenda was simple and to-the-point.

I started the day with the first two sessions, introducing everyone to WCF an then segueing them into more advanced binding and behavior configurations by showing the most commonly used configuration scenarios.  Seems that transaction handling was the more popular one there.  After lunch, one of our local DEs, Peter Laudati took the stage to talk about WCF REST capabilities.  After which, Don Demsak introduced everyone to WCF Data Services, rounding out the capability set of this technology.  I came back on at the end of the day to talk about the new WCF 4 stuff and it seems that routing capabilities was the highlight on that one.

  Peter and Don did an awesome job, as always.  As for my performance, I was happy but I’ll let others blog about what they thought.  All in all, I was comfortable with the outcome and I think the crowd was pleased.  We had about 200 attendees in the room and another 108 on LiveMeeting.  The event brought in people from around the country and world I think.  I put out a call for listeners to send me an email telling me where they are and immediately I received one from a listener in Southern Australia.  Kudos goes out to Coral who was listening in the middle of the night, down under.

When I took a poll at the beginning as to how many WCF users I had in the room, the count was extremely low (about 10) so I think this was definitely the target audience.

Thank you to Peter for getting Microsoft behind this event and for handling all the logistics, and thanks for letting me spearhead the agenda and content for the event.  I had a great time doing it.  O’Reilly was awesome and sent me 5 copies of Michele’s book and 5 of Juval’s to give away.  Also thanks to Developer Express and Telerik for donating product licenses for the event.  Both those companies can always be counted on to support these kind of events and their giveaways were the first ones to disappear.  Also, we had a tech out in Redmond with us every step of the way, monitoring the live feed and standing by in case of problems and we couldn’t have been more grateful to Erik Ostrowski for his help and for being there at 3am his time, to help us out.

As a goof, I have away a couple of “What Would Miguel Do?” t-shirts that a client of mine made for me.  I couldn’t believe it when one of the guys put it on and wore it for the entire event.  It was certainly flattering a very cool gesture.

I think that Danny, the DE down in the Philly market wants to put this event on in his territory so I guess that’s where we’ll be taking it next.

Thanks again to Microsoft, the local DEs, Don, and all the attendees and listener for help making it a great event.

Until next time…