Over the last week I’ve been slowly writing a little utility library to make it easier to express retry logic within application code. As software becomes more complex and more interconnected the concept of gracefully recovering from transient conditions becomes more important. Your average cloud or enterprise application is going to have to deal with network time outs, database deadlocks and temporary glitches caused by underlying systems recovering from hardware failures.

Palmer is a library that I’ve created to help solve this problem. You can read more about it over at GitHub. If you just want to download it and have a play, you can install the package from NuGet.

Install-Package Palmer

Using the API is easy with its fluent syntax:

Retry.On<SqlException>().For(5).With(context =>
{
  // Some code that might throw a transient SQL exception.
});

This is a 0.1 release so I am looking for feedback and ideas on how to improve the library. I’ve already got a couple of ideas such as:

• Extend the On/AndOn methods to allow passing in a typed exception to make accessing specific exception fields easier.
• Add event hooks to support logging exceptions as they occur.
• Create an extension library for common usage scenarios such as SQL, network issues.
• Support capturing multiple exceptions with one termination condition.

I’ve also added some issues around improving the documentation and turning the library back into a portable library after getting my build issues sorted out.

I’ve just posted four quick posts on three specific enhancements that I would like to see in the C# language.

• Automatic Property Initializers
• Backing Field Access
• Backing Field Type Declaration (in the absence of an initializer)

Obviously I would like to see all of the above features added to the language (after they have been thought through more fully by the language designers). However I do wonder how much further investment there is going to be in C# as a language. If you look at C# 5.0 we basically got async/await (and associated plumbing) and caller info. There was some suggestion that we might get automatic property initializers but that appeared to be scrapped.

Still – the “Roslyn” project does hold some promise in terms of opening up the compiler to allow software developers to transform the syntax of the code prior to compilation thereby supporting the addition of new language features.

Time will tell whether that is a good idea in terms of source code stability because in essence those language tweaks need to be part of source tree just like anything else, otherwise you might snooker yourself if you accidentally lost your Roslyn-based source code transformation add-in.

This is the third post which expands on two that I have already done tonight. The first was on adding an automatic property initializer syntax to C#, and the second was on adding backing field access from within the property accessors without having to separately specify the backing field.

My next suggested improvement is really just here for the purposes of completeness. Often you want to delay the creation of a backing filed instance until it is accessed. However, if you want to have a backing field which varies in type to the declared property then you need a way to specify the type of the backing field without actually instantiating it. Here is an example of the proposed syntax:

public class Customer
{
  public IEnumerable<Address> Addresses
  {
    get(field)
    {
      if (field == null) field = new Collection<Address>();
      return field;
    }
  } as Collection<Address>();
}

This code is pretty straight-forward. The backing field for the Addresses property is a Collection<Address>, but it is presented as an IEnumerable<Address>, and construction is deferred until it is accessed for the first time.

Potentially the syntax for optional arguments could be “borrowed” here to lead to a more concise syntax:

public class Customer
{
  public IEnumerable<Address> Addresses { get(field = new Customer<Address>()) }
}

In this case the type of the backing field could be inferred, the difference between the two being that the above syntax defers execution of the backing field initialization until the get accessor is called and the example from my automatic property initializer example is executed upon construction.

Identifying when, how and whom produced a product is important. It is important with physical goods, hence why we have barcodes, expiry dates, model and serial numbers. The same is also true for software. Embedding a version number in files that ship with a product allow support team members to determine what version of the source code went into produce that version of the product and therefore more easily debug its observed behaviour.

Later this week I was working with a fellow team member on automatically applying version numbers to our product each time that it built (continuously integrated). On the surface it is quite a simple task except when you start to consider the sheer number of places that version numbers should be applied within a relatively complex build process. Here are some common examples:

• .NET assemblies
• NuGet packages
• WiX installers
• Documentation files

Each one of these target locations requires a different approach for finding and updating version numbers and it end up getting pretty complicated. But before you start you might want to give some consideration to what your version number actually looks like, and what it means.

I take a lot of inspiration from SemVer.org but it doesn’t really work for all technologies. For example, strongly named assemblies in .NET have four elements (major.minor.build.revision) whereas SemVer defines three elements (major.minor.patch). SemVer also defines trailing elements followed by a dash (for example 1.0.9-rc1) which won’t work for the strong name in a .NET assembly. Of course we can use other informational versioning techniques to pass along SemVer like version information.

If we look at SemVer and apply the first part (major.minor.patch) to version numbers within the package then we could probably adopt a manual version increment technique and just take a centrally defined version number (say in version.xml in the root of the solution) and stamp it in various files during the build process.

Anyway – version numbers, they are important!