Git While the Gitting’s Good

Published on:
I saw an opening and I went for it.

After using git-svn for the past 5 months in a desperate attempt to keep my sanity in the face of a massive subversion repository, my team got a greenfield project. I honestly couldn’t help myself. “Ruby! Rails! Git! I’m on it!” So I became our de facto devops guy for a brand spanking new project, tasked with everything from configuring OpenSSH to installing Ruby and Rails on a severely locked down Windows system (many thanks once again to Luis Lavena and Wayne Seguin for making this possible) to learning about TortoiseGit to make our existing ToroiseSVN users feel comfortable.

For Git we’re using a standard SSH provisioning system on a remote repository. But my company does not allow Git on their central servers so our repository is hosted on a flaky VM with no guaranteed backups or failovers. That won’t do. To solve this, I decided to add the entire repository to my existing SVN repository.

Now that we’re official, I want to make sure that I keep backing things up. Here’s a script I adapted from an answer on StackExchange (thanks Robert Massaoli):


cd ..
while [ 1 ]
        svn add –force deployer.git/
        svn commit -m “GRT-0: Autocommitting deployer.git”

        sleep 600

Expecting (and Handling) the Unexpected

Published on:
In an earlier post I mentioned that I’m creating an unhandled exception manager inspired by Jeff Atwood’s Friendly Exception Manager. A couple of days ago we found a bug that crashed our application in UAT. Much to my dismay, no friendly exception message whatsoever was displaying for the user under these circumstances. But how could this be? I’m catching all unhandled exceptions for this very purpose!

Or am I? As it turns out, I was catching most, but not all, types of unhandled exceptions. Here’s where I started:
        public void AddHandler()
Application.ThreadException += ThreadExceptionHandler;
This is pretty simple and is ideally the first method called in your application after initializing your unhandled exception manager. (Those intimately familiar with Jeff Atwood’s version will notice that his exception managers are purely static. None of my objects are static and there are all kinds of interfaces and small helper objects in place, but the spirit remains the same.) The ThreadException event deals specifically with the UI thread. The handler is where the user notification takes place. However, there are two items that are unaccounted for.

First, my application is a combination of WPF and WinForms. The unhandled exception that crashed our application occurred in WinForms. Windows Forms errors do not behave the same way as ThreadExceptions by default and need to be told what to do. MSDN does a nice job of illustrating this somewhat confusing concept. The second thing I neglected was defining the behavior of non-UI thread exceptions. Our application relies heavily on the TPL library which gives us a big reason to be concerned with non-UI thread behavior. Luckily, we can relatively easily handle everything listed above with a few lines of code and an extra event handler (which, in my case, mirrors the functionality of the handler discussed above). The finished code looks like this:
        public void AddHandler()
AppDomain.CurrentDomain.UnhandledException += UnhandledExceptionHandler;
Application.ThreadException += ThreadExceptionHandler;

Exceptionally Lazy

Published on:
I’m working on a .NET project and have been building an Unhandled Exception Manager in the spirit of Jeff Atwood’s friendly exception handling. If a user encounters an error that will crash our application, the Unhandled Exception Manager steps in first and issues a friendly message. In the background it emails the development team about the exception in as much detail as it can possibly grab.

Recently some unwanted functionality gave me the opportunity to learn about lazy evaluation in C#. Look at the following code:
return MultiLine(
"Date and Time: " + DateTime.Now,
"Machine Name: " + Environment.MachineName,
"IP Address: " + Dns.GetHostEntry(Dns.GetHostName()).AddressList[0],
"Application Domain: " + AppDomain.CurrentDomain.FriendlyName,
"Assembly Codebase: " + _assemblyInfo.CodeBase,
"Assembly Full Name: " + _assemblyInfo.FullName,
"Assembly Version: " + _assemblyInfo.Version,
EnhancedStackTrace(new StackTrace(true))

Multiline simply aggregates the lines so that I can print pretty messages both in the code and in my emails:

static string MultiLine(params string[] args)
return string.Join(Environment.NewLine, args);

If any one of these nested calls throws an exception, we get an unhandled exception in the unhandled exception manager. Not good. Wrapping the whole thing in a try/catch prevents this but will not give us the maximum amount of information. If Dns.GetHostName returns null, for example, it would still be nice to get the MachineName and assembly information. The following MSpec test illustrates the problem:

[Subject(typeof (ExceptionMessageBuilder), "SystemInfo")]
class when_an_exception_is_thrown : ExceptionMessageBuilderSpec
private static Exception Exception;
private static Version Version;

private Establish context = () =>
Exception = new Exception();
Version = new Version(1, 0, 0, 254);
AssemblyInfo.WhenToldTo(x => x.FullName).Throw(Exception);
AssemblyInfo.WhenToldTo(x => x.Version).Return(Version);

private It will_handle_the_exception = () => ExceptionMessageBuilder.SystemInfo();

I was able to make this test pass and extract the maximum amount of information about my application crash using lazy evaluation:

public string SystemInfo()
return MultiLazy(new List<Lazy<string>>
{new Lazy<string>(() => "Date and Time: " + AppDomain.CurrentDomain.FriendlyName),
new Lazy<string>(() => "Machine Name: " + Environment.MachineName),
new Lazy<string>(() => "IP Address: " + Dns.GetHostEntry(Dns.GetHostName()).AddressList[0]),
new Lazy<string>(() => "Application Domain: " + AppDomain.CurrentDomain.FriendlyName),
new Lazy<string>(() => "Assembly Codebase: " + _assemblyInfo.CodeBase),
new Lazy<string>(() => "Assembly Full Name: " + _assemblyInfo.FullName),
new Lazy<string>(() => "Assembly Version: " + _assemblyInfo.Version),
new Lazy<string>(() => EnhancedStackTrace(new StackTrace(true)))

Using the Lazy<> syntax, I can state my intentions without executing any of the code. Instead, the CLR compiles the code and waits for .Value to be called on the arguments before executing.  A change to our MultiLine function demonstrates this in action:

static string MultiLazy(List<Lazy<string>> args)
var stringBuilder = new StringBuilder();
foreach (var arg in args)
// ReSharper disable EmptyGeneralCatchClause -- we want all the information we can get.
catch (Exception) {}
// ReSharper restore EmptyGeneralCatchClause
return stringBuilder.ToString();

Of course, this is my first attempt at lazy evaluation in C# and I’m open to other methods. Could this be cleaned up? Are there better approaches out there?