Light.GuardClauses 2.0 – It’s NetStandardized!

I just released version 2.0 of Light.GuardClauses. Check out this introductory video to learn about the new version:

This version brings new features and some breaking changes. Let’s check them out!

It’s NetStandardized!

Light.GuardClauses is a .NET Standard 1.0 library from now on. While running on all platforms that the old PCL 259 format supported, future platforms that will support .NET Standard 1.0 will also be able to use Light.GuardClauses without any further hassle. You don’t know .NET Standard yet? Then check out the official GitHub page and Immo Landwerth’s YouTube channel where he explains all the necessary details about the standard.

New features for Uri and collections

There are new assertion methods available for the Uri class: with MustHaveOneSchemeOf , you can check that a Uri is not null, absolute, and one of the specified schemes. This assertion forms the basis for MustBeHttpOrHttpsUrl, which internally calls MustHaveOneSchemeOf with the HTTP and HTTPS scheme. Additionally, there are simple MustBeHttpUrl and MustBeHttpsUrl extension methods.

For collections, there is a new extension method called AsReadOnlyList which tries to downcast an IEnumerable<T> to IReadOnlyList<T>, and if this is not possible, then a new list containing the enumerable’s items is returned. I often use this method internally in Light.GuardClauses, especially when I need index access in EnumerableAssertions, but I sometimes found it useful  in application code, too.

No COMPILE_ASSERTIONS any longer

Of course, there is a breaking change (otherwise I wouldn’t have raised the version number to 2.0, but would’ve continued with 1.4). And the breaking change is: COMPILE_ASSERTIONS is gone. Initially, I wanted Light.GuardClauses to be in line with Bertrand Meyer’s Design by Contract. This included that all calls to assertion methods could be included or excluded when the project was compiled. For that I used the ConditionalAttribute. However, I found this feature not that useful in my own projects, because with COMPILE_ASSERTIONS, I could only turn off all assertion methods or none of them. In reality, there is usually only a small piece of code where you want to deactivate precondition checks, usually for performance reasons.

Thus I removed COMPILE_ASSERTIONS completely in version 2. In turn, this allows the assertion methods to return the values being checked, which allows for method chaining of several assertion methods and to assign the return value of an assertion directly to a field, a variable, or any other target – just have a look at the following example:

public class Foo 
{
    private readonly IBar _bar;

    public Foo(IBar bar)
    {
        // Most assertion methods of Light.GuardClauses 2.0 
        // now return the value being checked, so you
        // can use method chaining or, like in this example, 
        // assign the return value directly to a field.
        _bar = bar.MustNotBeNull();
    }
}

If you want to exclude precondition checks in a certain piece of code, I would advise you to write your custom assertions that are marked with the ConditionalAttribute. Within these methods, you can still call the Light.GuardClause extension methods if you want to.

You like it? Then share it!

Check out the new version in your own code and on GitHub. You like it? Then please give it a thumbs up and share it with your coworkers and friends. You developed your own assertion method that others might find useful? Then send me a pull request!