Version 3 of my open source feature toggle library is now released to NuGet.

Version 3 introduces some breaking changes and new features.

Breaking Changes

• The WPF value convertor package has been removed for version 3 as it’s trivial to implement a version in individual applications and reduce the maintenance overhead for the porject
• Version 3 removes support for Windows Phone 8.0 (you can still use version 2.x if you need this support)

New Features

Platforms Support

In addition to .NET framework 4 full, version 3 also supports:

• Windows Phone 8.1 Silverlight apps
• Windows Universal Apps 8.1 (Store and Windows Phone 8.1 WinRT)
• Windows Store 8.1 apps

Future versions will add support for Windows 10 apps.

New Toggle Types

The EnabledOnOrAfterAssemblyVersionWhereToggleIsDefinedToggle (a little verbose I know) allows a feature to become enabled once a specified assembly version number is reached. The assembly version used is that of the assembly inside which the toggle is defined, rather that the executing assembly. The configuration value for this toggle would be (for example) 0.0.2.1.

Future version will add support for comparing the executing assembly version.

New Decorators

A new type of feature that version 3 introduces is the idea of toggle decorators. These are classes that “wrap” one or more toggles and provide additional features.

The DefaultToEnabledOnErrorDecorator and the DefaultToDisabledOnErrorDecorator allows a default value to provided if there is an error evaluating the wrapped toggle value, for example with a configuration error. These decorators should be used with caution as your application may end up in an unknown state if you forget to configure something properly. In some cases you may want this behaviour rather than the application failing.

Assuming that a feature toggle called MyFeatureToggle has been defined, to use the decorator the following code would be used.

IFeatureToggle printFeatureThatDefaultsToDisabled = new DefaultToDisabledOnErrorDecorator( new MyFeatureToggle() );

bool isPrintEnabled = printFeatureThatDefaultsToDisabled.FeatureEnabled;

These decorators also allow you to specify an optional logging action that gets called if the wrapped toggle throws an exception:

new DefaultToDisabledOnErrorDecorator(wrappedToggle, ex => Console.WriteLine(ex.Message));

The CompositeAndDecorator allows multiple toggles to be wrapped, only if all these wrapped toggles are enabled will the decorator return true.

IFeatureToggle andToggle = new CompositeAndDecorator(new AnEnabledFeature(), new ADisabledFeature());

var isEnabled = andToggle.FeatureEnabled; // returns false

The final new decorator is the FixedTimeCacheDecorator. This allows a toggle that gets its value from a slow source (such as remote database, http, etc.) to have its value cached for a fixed period of time. To use this you specify the wrapped toggle and a TimeSpan.

IFeatureToggle cachedToggle = new FixedTimeCacheDecorator(cachedToggle, TimeSpan.FromSeconds(10));

Check out the release notes on GitHub. If you find any problems or bugs or want to suggest other features, please create an issue on GitHub.

SHARE:

The next version of my open source feature toggling library is currently in development.

Version 3 will introduce a number of new features and retire support for some older platforms. For the currently implemented changes (not yet released at the time of writing) see GitHub release notes, and the complete list of v3 issues/features.

Some notable additions include some new toggle types to enable scenarios such as automatically enabling a feature once the assembly version number meets or exceeds a specific version and decorators to allow a toggle to default to on or off if the underlying toggle errors in some way, such as missing configuration or network error while retrieving the toggle value from a remote source such as SQL Server.

Once v3 development is complete it will be available via NuGet.

SHARE:

Feature toggles (also referred to as feature flags, flippers, feature switches, etc) are a technique to turn on or off features in applications. One way of categorising feature toggles is whether they are for the benefit of the development team (“release toggles”) or the business/stakeholders (“business toggles”). Release toggles are an alternative/compliment to feature branching and are short lived. Business toggles are long lived and represent application features that are enabled depending on business defined rules.

In my new Pluralsight course Implementing Feature Toggles in .NET with FeatureToggle I talk about the different types of toggles and some general things to consider when using toggles, followed by modules showing how to use the FeatureToggle open source library.

You can start watching with a Pluralsight free trial.

SHARE:

An issue was raised about .NET 4 support. This was caused by FeatureToggle.Core having incorrect NuGet PCL target.

Version 2.2.1 is now released that should resolve this and allow use of FeatureToggle in .Net 4 apps.

(The Raven package is still targeting 4.5.1 however.)

SHARE:

Release 2.2 of FeatureToggle is now available via NuGet.

This release adds a single new toggle: HttpJsonFeatureToggle.

This toggle gets it's enabled state from a JSON HTTP endpoint.

Configuration should be the url where the JSON configuration lives, e.g:

<add key="FeatureToggle.HttpJsonTrueToggle" value="http://localhost:8084/api/test/getenabled" />

As with all the toggles, if url is not available then an exception will be raised, rather than assuming either enabled or disabled.

The expected JSON that should be returned is in the form:  {"enabled": true} or  {"enabled": false}

Documentation here.

I’m thinking the next major release will be Version 3, planned changes here.

SHARE:

My open source fetaure toggling library contains a number of prebuilt toggles for common things such as enabling a feature based on the date, or a configuration value.

It’s also easy to create custom toggles by implementing IFeatureToggle.

Up to now, FeatureToggle has mainly been an aid for continuous delivery; a “half done” feature can simply be configured off so it doesn’t appear in the UI.

I’m wondering if the following approach has merit, namely treating conditionally available features as a first class citizens. So this is not just using them for continuous delivery but to encapsulate actual features of the application.

The example below requires 3 NuGet packages:

• FeatureToggle.Core
• FeatureToggle.WPFExtensions
• MVVMLight

So the feature in the application will restrict the availability of mature rated games to customers who are 18+.

First off the feature toggle:

using FeatureToggle.Core;

namespace CustomFeatureToggle
{
    class MatureTitleSelectionFeature : IFeatureToggle
    {       
        public MatureTitleSelectionFeature(Customer customer)
        {
            FeatureEnabled = customer.Age >= 18;
        }

        public bool FeatureEnabled { get; set; }
    }
}

Here the business logic is encapsulated in the feature toggle and can be tested.

Next the viewmodel:

class MainViewModel : ViewModelBase
{
    private Customer _selectedCustomer;
    private IFeatureToggle _matureTitlesFeature;
    private ObservableCollection<Customer> _customers;

    public MainViewModel()
    {
        Customers = new ObservableCollection<Customer>
                    {
                        new Customer {Name = "Sarah", Age = 32},
                        new Customer {Name = "Robert", Age = 17}
                    };

        SelectedCustomer = Customers[0];

        MatureTitlesFeature = new MatureTitleSelectionFeature(SelectedCustomer);
    }

    public ObservableCollection<Customer> Customers
    {
        get
        {
            return _customers;                 
        }
        set
        {
            _customers = value; 
            Set(() => Customers, ref _customers, value);                 
        }
    }

    public Customer SelectedCustomer
    {
        get
        {
            return _selectedCustomer;
        }
        set
        {
            _selectedCustomer = value;
            
            Set(() => SelectedCustomer, ref _selectedCustomer, value);

            MatureTitlesFeature = new MatureTitleSelectionFeature(SelectedCustomer);
        }
    }

    public IFeatureToggle MatureTitlesFeature
    {
        get
        {
            return _matureTitlesFeature;
        }
        set
        {
            _matureTitlesFeature = value;

            Set(() => MatureTitlesFeature, ref _matureTitlesFeature, value);
        }
    }
}

Here, every time the selected customer changes, a new (immutable) toggle is created based on the customer’s details, i.e. Age.

The visibility in the UI of mature titles is simple data binding, using a visibility convertor from FeatureToggle.WPFExtensions.

<Window x:Class="CustomFeatureToggle.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:toggles="clr-namespace:FeatureToggle.Toggles;assembly=FeatureToggle.WpfExtensions"
        Title="MainWindow" Height="350" Width="525">
    <Window.Resources>
        <toggles:FeatureToggleToVisibilityConverter x:Key="ToggleVisConverter"></toggles:FeatureToggleToVisibilityConverter>
    </Window.Resources>
    <Grid>
        <StackPanel>
            <ComboBox DisplayMemberPath="Name" 
                      ItemsSource="{Binding Customers, Mode=TwoWay}"
                      SelectedItem="{Binding SelectedCustomer}"></ComboBox>
            <TextBlock>All audience titles here</TextBlock>
            <TextBlock Visibility="{Binding MatureTitlesFeature, Converter={StaticResource ToggleVisConverter}, Mode=TwoWay}">Mature titles here</TextBlock>
        </StackPanel>
    </Grid>
</Window>

SHARE:

Version 2.1 of my open source feature toggling library has just been released.

This new version contains two new toggles.

The RandomFeatureToggle as its name suggests will randomly enable/disable a feature.

The EnabledOnDaysOfWeekFeatureToggle allows configuration of a toggle to become enabled on specific weekdays.

Check out the documentation and release notes for more info.

SHARE:

I just published new NuGet package for my open source .NET feature toggling library.

This package allows you to turn features on/off depending on what’s configured in a RavenDB database.

PM> Install-Package FeatureToggle.RavenDB

Extract from documentation:

BooleanRavenDBFeatureToggle

This toggle is not available on Windows Phone or Windows Store apps.

This toggle get it’s value from a RavenDB database.

Create a Toggle for the feature you want to control by inheriting from BooleanRavenDBFeatureToggle:

private class SaveToPdfFeatureToggle : BooleanRavenDBFeatureToggle{ }

Add RavenDB connection string to app/web config:

<connectionStrings>
    <add name="FeatureToggle.SaveToPdfFeatureToggle" connectionString="Url = http://localhost:8080;database=FeatureToggleInterationTests"/>    
</connectionStrings>

The database should contain a collection called “BooleanToggleSettings” with a document for every toggle that contains a property “Enabled”:

{
  "Enabled": true
}

Check out the test setup to see an example of writing some toggle config entries.

SHARE:

Version 2 of my open source feature toggling .Net library has just been released to NuGet.

V2 introduces a number of breaking changes – see release notes. It also include binary Windows Store DLLs as opposed to code-only.

Version 2 will form the base for new feature in the future.

FeatureToggle.Core has been introduced as a portable class library.

For more details see the documentation, or the examples.

SHARE:

I just released an update to my open source feature toggling library FeatureToggle.

Version 1.2.0 add support for using feature toggles in your Windows 8 WinRT .Net (C#) app. For this initial release, the NuGet package for Windows8 app installs the source code, rather than a binary reference. This is so it will always build to whatever architecture you are compiling against (Any CPU, x86, x64, ARM).

This release also provides a XAML value converter (FeatureToggleToVisibilityConverter) to make binding the visibility of UI element to a feature toggle easier.

What To Use Feature Toggles For

Typically feature toggles (sometimes called feature flags, flippers, etc.) enable you to keep one branch of source code and deploy code to production with “half done” stuff. This half done stuff is (typically) toggled at the UI level so it is not available to users.

With Windows 8 in-app-purchases (IAPs), you could also use the FeatureToggle library as a unified way of enabling those extra IAP features that a user has paid for.

Getting Started with FeatureToggle in a Windows 8 App

Install FeatureToggle NuGet Package

Create a new Visual C# Windows Store project (Blank App XAML is fine for this demo).

Install the FeatureToggle NuGet package by either:

• Right0click project, Manage NuGet Packages, search for FeatureToggle, click the Install button; or
• In the Package Manager Console window, type “Install-Package FeatureToggle” and hit enter.

You will notice two folders added to the project: “FeatureToggleCode” (which you don’t need to change) and “FeatureToggleSample” which contains an example toggle.

Create a Feature Toggle

Create a new class called “AwesomeFeature” that looks like this:

internal class AwesomeFeature : JasonRoberts.FeatureToggle.AlwaysOffFeatureToggle
{
}

More...

SHARE: