using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;

namespace GibraltarGettingStartedApp
{

	class Program
	{
		static int Main(string[] args)
			{
				Trace.WriteLine("About to Blow up...");
				int zero = 0;
				Trace.Close();
				return 1 / zero;
			}
		}
	}
}

That should get the runtime’s panties in a bunch, let’s try it.

Yep, that did it! Now, let’s see what Gibraltar logged…

Gibraltar knows we crashed and if we open up the record…

We know what the problem was, we can click the link and go right to the line in the source code and Gibraltar tells us what the user experience is going to be, “This fatal error will not be reported to the user, then the application will exit”. All and all, pretty cool.

As an aside, let me close down VS, I want to test if I click the link, will it open the file and go to the line? It does! That’s cool, though I notice that it only opens the actual file and not the solution or project that the file is in. Hmm, I’ll need to investigate that more as it’d be better if the entire solution was opened, don’t you think?

Let’s try running the same unhandled exception in a winforms application and see what happens. We’ll need to run the exe from the commandline, as the VS debugger will “get in the way” and try to do “clever stuff”, but when we do, we see the following dialog:

Here Gibraltar is giving us even more help. It’s popped up a dialog which will actually help us recover from the crash and carry on using our application. If we select “Restart Application” Gibraltar will restart the application for us and enable us to carry on using our application. Of course, this facility should only be used in a testing environment. In the real world, I don’t think it would be wise to restart and to continue using an application which had just suffered from a crash, as there is no way to know what state the underlying model is in. However, from a testing perspective, it’s an excellent tool.

Of course, the same information is recorded in Gibraltar:

Notice that the “Status” has been recorded as “Normal”. If we open the record we can see why:

It’s because we chose to continue the execution and shut down the application normally after.

Okay, let’s change our console application code to handle the exception…

using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;

namespace GibraltarGettingStartedApp
{
	class Program
	{
		static int Main(string[] args)
		{
			Trace.WriteLine("About to Blow up...");
			int zero = 0;
			Trace.Close();
			try { return 1 / zero; }
			catch (DivideByZeroException e) { }
			return 0;
		}
	}
}

And let’s see what difference that made to Gibraltar…

Hmm, as far as Gibraltar is concerned everything is normal, there is no sign of the handled exception. For a clue as to why that is, let’s examine logging best practices, you can read them at…

http://www.gibraltarsoftware.com/Support/Documentation/Logging_BestPractices.html

And they quite clearly state:

“We strongly recommend that in all cases where an exception is consumed within a catch block that you log the exception with an Informational severity rather than silently swallowing the error.”

Okay, so this states that if we handle an exception, and we want that fact recorded by Gibraltar, then we have to log it. That makes sense really. So, let’s change our code to the following:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;

namespace GibraltarGettingStartedApp
{
	class Program
	{
		static int Main(string[] args)
		{
			Trace.WriteLine("About to Blow up...");
			int zero = 0;
			try { return 1 / zero; }
			catch (DivideByZeroException e)
			{
				Trace.WriteLine("Error: " + e.Message);
			}
			Trace.Close();
			return 0;
		}
	}
}

Now let’s see how that’s affected Gibraltar:

This time you can plainly see that the error has been recorded, which is good, but notice too that there’s no exception tab:

Of course, we should be able to do better and we can. If we use the TraceInformation method, and pass a formatted string, along with the exception, then Gibraltar will give us a much richer experience.

So, let’s change our code to use that method:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;

namespace GibraltarGettingStartedApp
{
	class Program
	{
		static int Main(string[] args)
		{
			Trace.WriteLine("About to Blow up...");
			int zero = 0;
			try { return 1 / zero; }
			catch (DivideByZeroException e)
			{
				Trace.TraceInformation("Error: {0}",e.Message,e);
			}
			Trace.Close();
			return 0;
		}
	}
}

And let’s look at the information provided in Gibraltar:

This time, as you can see, we get the “Exceptions” tab. This is because Gibraltar scans the insertion variables and, if it finds one that is an exception, then it uses that as the exception for the log message (regardless of its severity). Pretty cool eh?

In this post we added an unhandled exception to your console application to see what effect that had on Gibraltar. We then added an unhandled exception to a winforms application so we could see the enhanced features available to us there and then we finished up by handling that exception and seeing why best practice is to log handled exceptions.

I hope you’ll join me next time as we continue our exploration of Gibraltar, until then, happy coding!

Now I’ve never used the product and I don’t know anything about it, so I guess I’m on the same sort of learning curve as a new customer when they first download a trial version.

We all learn in different ways and at different speeds, but the way I learn best is through action centred learning, in other words, I like to “do stuff” to learn how “stuff works”. So, the best way for me to learn how to do something with Gibraltar, is to do something with Gibraltar.

So what’s the simplest thing I can do to get something working? Well after having a quick look at the documentation, it seems to me that the simplest thing to do is:

1. Configure a minimalist application for tracing
2. Hook up Gibraltar
3. Examine the data in Gibraltar.

Okay, so let’s do that!

Step 1. Configure a Minimalist Application For Tracing

Let’s work with the simplest thing, namely a console application with one method and a couple of calls to the Tracing API. Something like this should fit the bill:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;
using Gibraltar.Agent;

namespace GibraltarGettingStartedApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Trace.WriteLine("Entered method!");
            Console.WriteLine("In the body of the method!");
            Trace.WriteLine("Leaving method!");
        }
    }
}

And when we run this, it does pretty much as we’d expect it to do:

Step 2. Hook up Gibraltar

Firstly, start Gibraltar and from the and click the “Add Gibraltar Now” button:

Then, simply work your way through the wizard. Starting with selecting the project file for your application:

Next, since we’re doing the simplest thing possible, accept the default configuration:

Then deselect all the checkboxes.With the exception of “Allow Sessions to be Emailed to you”, which I can guess at, I have no idea what these do, but we’ll find out later. For now, we just want to do the simplest thing that’ll work.

And we’re done:

Okay so let’s run our application again.

Hmm, notice that the console window stays open this time, and we have to physically close it to make our application end – what’s happening here I wonder? We’ll come back and investigate that in a moment, but for now, let’s see what information is available in Gibraltar.

Step 3. Examine the Data in Gibraltar

Open Gibraltar and select “New Sessions”

and in the right hand pane, we see that we do indeed have information from our application!

Now it’s time to investigate that “application is still running” oddity. Looking at the information we can see that the “status” is  “crashed”, even though we closed it down properly.

My guess as to what is going on here is that the Gibraltar Agent is holding open the application after the execution path has reached the end of the Main() method. We then closed the window manually, and because our application didn’t end in the way Gibraltar expected, it’s marked this event as a “crash”. It’s time to look up the documentation and find out what’s going on.

A quick read of the documentation at:

http://www.gibraltarsoftware.com/Support/Documentation/WinForms_DevelopersReference_EnsureYourApplicationExits.html

Shows us that indeed, when we are using a console application, we are responsible for ending the session. We can also see that there are a number of ways to do this, but since we are trying the simplest possible thing that will work, we’ll just add the Trace.Close() call to the end off our application. So now our code looks like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;
using Gibraltar.Agent;

namespace GibraltarGettingStartedApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Trace.WriteLine("Entered method!");
            Console.WriteLine("In the body of the method!");
            Trace.WriteLine("Leaving method!");
            Trace.Close();
        }
    }
}

If we run our application now, we can see that our application closes when we get to the end of the Main() method. If we look in Gibraltar we can also see that our application has closed normally:

Okay, I think that is enough for this post. To help us learn how Gibraltar works, we’ve build a minimalist application and enabled Gibraltar to record our trace information. In the next post, we’ll build on these beginnings by looking at what happens when our application throws and error. We’ll also find out if Gibraltar deals with handled and unhandled exceptions differently.

Until next time, happy coding!

We’ve just released sample code (both source and binary) that will ultimately form the basis for built-in Silverlight and Windows Phone support in a future version of Gibraltar.  It supports Silverlight 3 & 4 as well as Windows Phone 7.x. You can use on binaries as-is (we even provide a NuGet package to make it super easy to integrate), or you can start with our implementation then tweak the code as you wish. Either way, it gives you an easy way to get a more complete picture from your Gibraltar logs today including both client- and server-side logging.

Please check out the bits and let us know what you think!

Understanding the Design
Our support for Silverlight comes in two parts: a client-side library that is a subset of the current Gibraltar.Agent shipping release, and a server-side AgentConnector that acts as the “message sink” for each Silverlight client that writes client-side messages to the Gibraltar log, which is then packaged up and pushed to the Hub and/or Analyst just as you would expect.

The Agent Connector is a REST-based WCF service that leverages WebActivator to automatically configure the service route, give you near-zero-config that will have you up and running in less than 5 minutes.

Log messages are continuously streamed from each client to your web application with client-side message buffering to ensure that no more than one outbound request to to the Agent Connector is active at once for each client. Server-side, each client is assigned a unique ID to make it easy to analyze multi-user behaviors and trace individual client sessions from Gibraltar Analyst.

Getting the Bits
There are two different ways you can get the code. The first is through NuGet.org. If you’re not familiar with NuGet, it is a free Visual Studio extension that manages assembly dependencies including automatic downloads and updates. The “Server” component of this design leverages NuGet to pull down Gibraltar.Agent, as well as WebActivator, so either way, you’ll want to check it out.

The second option is to download a zip file containing the same binaries included in the NuGet packages as well as the full source code, an end-to-end sample application and a ReadMe file with details on building and integrating the code.

Installing the Server Bits with NuGet
Your solution will likely have two parts, a Silverlight client app, and a Web Application. To start, you’ll want to have the NuGet Package Manager installed in VS2010. You’ll also want to have already configured the Gibraltar Agent on your web app. If you have not done so, please follow the directions on this page of our User’s Guide.

Right-click your web project, and select “Manage NuGet Packages”. In the resulting window, type “Gibraltar.Agent” into the search box in the top-right corner. You should be presented with a number of packages. Select ‘Gibraltar Agent for Silverlight – Server”. This will add the assembly references, as well as a clientaccesspolicy.xml file, to the root of your app. You can also open up the NuGet Package Console and type “Install-Package Gibraltar.Agent.Silverlight.Server”, which will accomplish the same thing.

Installing and Configuring the Client Bits with NuGet
Now right-click your Silverlight project, call up the NuGet Package Manager again, run the same search, and this time select the “Gibraltar Agent for Silverlight – Client” package. You can also open up the NuGet Package Console and type “Install-Package Gibraltar.Agent.Silverlight.Client”. After it installs the proper assemblies for your project type (the same package has the SL3, SL4, and WP7 binaries), there is one more thing you’ll need to do. You need to add the following string to the ResourceDictionary in your App.xaml file:

<system:String x:Key="GibraltarAgentServer">http://YOURSITEHERE.com/</system:String>

This value needs to be the root of your application, be it a domain, subdomain, or IIS application. This will be combined with the built-in WCF route auto-registered by the Server binaries (“/GibraltarAgentService/”, to be exact). Now, you should be able to use Gibraltar.Agent.Log just like you always have:

Log.TraceCritical("This is a critical message.");

Since multiple clients will likely be connected, the service assigns each IP address a unique integer ID, so you can easily track which messages come from which clients or have Gibraltar filter the view to only show messages from a single client. You’ll see results similar to the screenshot below:

Well, there you have it. Get the bits and tell us what you think. Even with this early sample, we’ve sought to make it as robust and forgiving as possible, in line with our goal to “First, Do No Harm”. Your feedback will help us extend and harden our Silverlight support and become an easy-to-use and rock-solid part of the standard distribution for a future Gibraltar version. So, if you find any issues, please do not hesitate to leave a comment and let us know.

Kendall Miller presented a new talk at this Code Camp – Easy Application Scaling with Microsoft AppFabric and AOP.  You can read the slides below as well as download the source code for the demos.  This is an extended version of the webinar we did a few months ago, with a lot more code samples.

The key idea is that AppFabric cache creates a number of opportunities for high performance, highly scalable applications but you’ll want to do some up-front work to make it easy to use in your application.  The code samples walk through how to do it all by hand, then show how to use PostSharp to inject the code at compile time and make it a whole lot easier.  You can Download the Code to see for yourself

Philly .NET was very well run as usual – all the food set up and ready to go, good places to network, lots of tracks and sessions to attend.  This year they also added an open spaces area for folks to hotly debate common challenges in a semi-moderated forum.  It was a fun place to sit and listen to the passionate, divergent opinions on the range of software construction topics. Of course we were happy to see our friends from DevExpress there as well as the rest of the community.