Reducing Magic Strings with Microsoft Feature Toggles (Microsoft.FeatureManagement)

This is the second part in a series.

EDIT: my Feature Management Pluralsight training course is now available.

One of the downsides of Microsoft’s feature flags/feature toggle implementation is the reliance on magic strings in code to query the status of features.

For example, the following code checks for the state of the Printing feature:

if (await _featureManager.IsEnabledAsync("Printing"))
{
    ViewData["PrintMessage"] = "On";
}
else
{
    ViewData["PrintMessage"] = "Off";
}

Notice in the preceding code that the feature is referenced with the string “Printing”. These kind of magic strings in code can be problematic because they have no sematic compiler meaning, for example if the feature is mentioned in multiple places and the name of the feature changes in configuration you would need to update all the strings in the codebase. It is easy to miss one and then end up with errors in the app.

In the documentation, the recommended approach is to define an enum containing the feature you want to control, for example:

public enum Features
{
    Printing,
    QuickQuotes,
    OnlineChat
}

Now the code can be refactored to make use of the enum in conjunction with a nameof expression:

if (await _featureManager.IsEnabledAsync(nameof(Features.Printing)))
{
    ViewData["PrintMessage"] = "On";
}
else
{
    ViewData["PrintMessage"] = "Off";
}

There are a number of things that can (and should) happen when using feature toggles/flags. One of which is that when a feature becomes permanent then the toggle and associated code should be removed. First this means removing it from configuration, which as I mentioned in part 1 will not actually break anything. The next step will be to remove it from the enum, doing this will actually break compilation (which is a good thing) if the enum value is referenced in a nameof expression. The next step is to fix compilation errors by removing the conditional code that relies on the flag/toggle.

In part 1 I mentioned the <feature> tag helper that can be used to enable/disable UI elements based on a flag:

<feature name="Printing">
    <li class="nav-item">
        <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Print">Print Preview</a>
    </li>
</feature>

Notice in the preceding HTML that the name of the feature is still represented as a magic string “Printing”. If the enum value and config are removed, compilation will not beak if this HTML still exists. We can fix this by one again using nameof in the view:

<feature name="@nameof(Features.Printing)">
    <li class="nav-item">
        <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Print">Print Preview</a>
    </li>
</feature>

Now if we removed Printing from the enum we get a compilation error and we won’t accidentally release an app to production with incorrect UI elements.

Be sure to check out my Microsoft Feature Management Pluralsight course get started watching with a free trial.

SHARE:

Using the Microsoft Feature Toggle Library in ASP.NET Core (Microsoft.FeatureManagement)

This is the first part in a series.

EDIT: my Feature Management Pluralsight training course is now available.

As the creator of the open source FeatureToggle library for .NET it was with some interest that I learned about Microsoft’s own offering to the feature toggle/feature flags landscape.

Microsoft’s offering is know as “.NET Core Feature Management” and they use the term “feature flag” in place of other terms such as “feature toggle”, “feature flappers”, etc. The root namespace is “Microsoft.FeatureManagement”.

Getting Started with Microsoft Feature Management in ASP.NET Core

As a simple example, first create a new ASP.NET Core 3.1 web app project with MVC support and then install the Microsoft.FeatureManagement.AspNetCore NuGet package.

Next, open the Startup.cs class, add a using directive for Microsoft.FeatureManagement and opt in to feature management:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();

    services.AddFeatureManagement();
}

Feature flags can be configured in a number of ways, such as in appsettings.json, environment variables, and Azure App Configuration.

Open up the appsettings.json file and add a feature to be managed in a new FeatureManagement section, for example the following defines a feature called “Printing”:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "FeatureManagement": {
    "Printing": true    
  }
}

In the preceding json, the Printing feature is currently enabled.

Now we have a configured feature flag/toggle we can make use of it.

Programmatically Querying Feature Flags in Controllers

If you want to execute conditional logic in a controller based on a feature flag you can do this by first getting a reference to an IFeatureManager. To do this, it can be injected as a dependency into the controller via its constructor:

private readonly IFeatureManager _featureManager;

public HomeController(IFeatureManager featureManager)
{
    _featureManager = featureManager;
}

Now the IFeatureManager instance can be used to make decisions by calling the IsEnabledAsync method and providing the string of the feature that was configured in the appsettings.json – in this case “Printing”:

public async Task<IActionResult> Index()
{
    if (await _featureManager.IsEnabledAsync("Printing"))
    {
        ViewData["PrintMessage"] = "On";
    }
    else
    {
        ViewData["PrintMessage"] = "Off";
    }
    
    return View();
}

In the view you could have some HTML to output the contents of the PrintMessage viewdata:

@{
    ViewData["Title"] = "Home Page";
}

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <p>Printing is currently @ViewData["PrintMessage"]</p>
</div>

In the controller you could of course do more complex logic such as calling additional services or swapping out different algorithms based on flags.

One thing I don’t like about the FeatureManagement library is that if a flag is not configured or has a typo in the configuration, then the app still runs with the feature disabled. By default I think that the app should error if  a flag is used but not defined, otherwise you may have important features/logic that does not get executed; I feel that the sooner you know about these kind of problems the better. For example some important legal/compliance text might not be shown when it should.

Managing Controllers and Actions Based On Feature Flags

Controller actions (and also entire controllers) can be enabled/disabled based on a feature flag. For example an action could be based on the printing flag by decorating the action method with the [FeatureGate] attribute as follows:

[FeatureGate("Printing")]
public IActionResult Print()
{
    return View();
}

If you try and navigate to the Print page when the flag is disabled then you’ll get a 404.

You can also apply the [FeatureGate] attribute at the controller class level and this will affect all actions contained therein.

Modifying The Generated HTML View Based On Flags

Sometimes you will have UI elements that should be shown or hidden based on a flag.

To control an entire block of HTML you can surround it with the <feature> tag. To enable this you should first modify _ViewImports.cshtml and add the tag helper as shown below:

@using WebApplication1
@using WebApplication1.Models
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
@addTagHelper *, Microsoft.FeatureManagement.AspNetCore

As an example, suppose we have disabled the Print page/action – we would also not want it to be displayed in the menu. We could modify the HTML to make the menu item display conditional on the Printing flag:

<nav class="navbar navbar-expand-sm navbar-toggleable-sm navbar-light bg-white border-bottom box-shadow mb-3">
    <div class="container">
        <a class="navbar-brand" asp-area="" asp-controller="Home" asp-action="Index">WebApplication1</a>
        <button class="navbar-toggler" type="button" data-toggle="collapse" data-target=".navbar-collapse" aria-controls="navbarSupportedContent"
                aria-expanded="false" aria-label="Toggle navigation">
            <span class="navbar-toggler-icon"></span>
        </button>
        <div class="navbar-collapse collapse d-sm-inline-flex flex-sm-row-reverse">
            <ul class="navbar-nav flex-grow-1">
                <li class="nav-item">
                    <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Index">Home</a>
                </li>
                <li class="nav-item">
                    <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Privacy">Privacy</a>
                </li>
                <feature name="Printing">
                    <li class="nav-item">
                        <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Print">Print Preview</a>
                    </li>
                </feature>
            </ul>
        </div>
    </div>
</nav>

Notice in the preceding HTML that the <feature name=”Printing”> element is wrapped around the printing menu option <li>.

Now if the Printing flag is set to true the menu item will be shown, otherwise it won’t appear in the rendered HTML.

Be sure to check out my Microsoft Feature Management Pluralsight course get started watching with a free trial.

SHARE:

Microsoft Feature Toggle Feature Flag Library: A First Look

EDIT: my Feature Management Pluralsight training course is now available.

As the creator of the .NET FeatureToggle library that has over half a million downloads on NuGet, I recently learned (thanks @OzBobWA) with some interest that Microsoft is working on a feature toggle / feature flag library.

It’s in its infancy at the moment and is currently in early preview on NuGet and as I understand it, the library is being developed by the Azure team and is not currently open sourced/available on GitHub.

Essentially the library allows you to configure whether a feature is on or off depending on a configuration setting, such as defined in the configuration JSON file or in Azure configuration.

Whilst the development of the library appears to be currently focused on enabling feature toggling in ASP.NET Core, I though it would be interesting to see if I could get it to work in a .NET Core console app. I hacked together the following code to demonstrate:

using System;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.FeatureManagement;

namespace ConsoleApp1
{
    class Program
    {
        static readonly IFeatureManager FeatureManager;

        static Program()
        {
            // Setup configuration to come from config file 
            IConfigurationBuilder builder = new ConfigurationBuilder();
            builder.AddJsonFile("appsettings.json");
            var configuration = builder.Build();

            // Register services (including feature management)
            var serviceCollection = new ServiceCollection();
            serviceCollection.AddSingleton<IConfiguration>(configuration);
            serviceCollection.AddFeatureManagement();

            // build the service and get IFeatureManager instance
            var serviceProvider = serviceCollection.BuildServiceProvider();
            FeatureManager = serviceProvider.GetService<IFeatureManager>();
        }

        static void Main(string[] args)
        {
            if (FeatureManager.IsEnabled("SayHello"))
            {
                Console.WriteLine("Hello World!");
            }


            Console.WriteLine("Press any key to exit...");
            Console.ReadLine();
        } 
    }
}

This code requires the following NuGets:

    <PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="3.0.0-preview6.19304.6" />
    <PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="2.2.0" />
    <PackageReference Include="Microsoft.FeatureManagement" Version="1.0.0-preview-009000001-1251" />

The console app attempts to read from the appsettings.json file and looks in the FeatureManagement section to see whether features are enabled or not:

{
  "FeatureManagement": {
    "SayHello": true
  }
}

In the code, strings are used to evaluate whether a feature is enabled or not, e.g. the line: if (FeatureManager.IsEnabled("SayHello"))  looks for a configuration value called “SayHello”.

If this value is false, the Console.WriteLine("Hello World!"); will not execute; if it is true the text “Hello World!” will be output.

Comparing Microsoft.FeatureManagement to FeatureToggle

When compared to the FeatureToggle library there are some interesting differences, for example the same app created using the FeatureToggle library would like the following:

using System;
using FeatureToggle;

namespace ConsoleApp2
{
    class SayHelloFeature : SimpleFeatureToggle { }

    class Program
    {
        static void Main(string[] args)
        {
            if (Is<SayHelloFeature>.Enabled)
            {
                Console.WriteLine("Hello World!");
            }

            Console.WriteLine("Press any key to exit...");
            Console.ReadLine();            
        }
    }
}

Notice in the preceding code that there are no magic strings to read the toggle value, instead you define a class that represents the feature and then by convention, the name of the class is used to locate the toggle value in configuration which looks like:

{
  "FeatureToggle": {
    "SayHelloFeature": "false"
  }
}

Overall ,whilst it is still early days for the library, it is cool that Microsoft may have their own supported feature toggling library in the future and help bring the concept of feature toggles as an alternative/adjunct to feature branches in source control to “the masses”.

SHARE:

FeatureToggle v4 Released

Version 4 of FeatureToggle is now released. This release adds initial support for .NET Core.

Example code.

Release notes.

Breaking Changes:

  • Min framework now 4.6.1 / .NET Standard 1.4
  • Windows 8.n, Windows phone 8.n, Windows Phone Silverlight 8.n no longer supported
  • Namespace changes: most types needed for application developers are now under root FeatureToggle namespace
  • Types not usually required by client code moved to FeatureToggle.Internal
  • Windows UWP now supported explicitly from build 14393

.NET Core Limitations/Specifics

This is in some ways somewhat of an interim release, it is envisaged that when version 5 comes around the implementation will move to a pure .NET Standard implementation.

SHARE:

Mocking with FeatureToggle

I was asked a question on Twitter so I thought I’d write it up here.

When using the FeatureToggle library you may have some some code that behaves differently if a toggle is enabled.

When writing a test, you can create a mock IFeatureToggle and set it up to be enabled (or not) and then assert the result is as expected.

The following code show a simple console app that has an OptionsConsoleWriter.Generate method that uses a toggle to output a printing feature option:

using static System.Console;
using System.Text;
using FeatureToggle.Toggles;
using FeatureToggle.Core;

namespace ConsoleApp1
{
    public class Printing : SimpleFeatureToggle {}

    public class OptionsConsoleWriter
    {
        public string Generate(IFeatureToggle printingToggle)
        {
            var sb = new StringBuilder();

            sb.AppendLine("Options:");
            sb.AppendLine("(e)xport");
            sb.AppendLine("(s)ave");

            if (printingToggle.FeatureEnabled)
            {
                sb.AppendLine("(p)rinting");
            }

            return sb.ToString();
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Printing printingToggle = new Printing();

            string options = new OptionsConsoleWriter().Generate(printingToggle);

            Write(options);            

            ReadLine();
        }
    }
}

To write a couple of simple tests for this method, you can use a mocking framework such as Moq to generate a mocked IFeatureToggle and pass it to the Generate method:

using Xunit;
using Moq;
using FeatureToggle.Core;
using ConsoleApp1;

namespace ClassLibrary1.Tests
{
    public class OptionsConsoleWriterTests
    {
        [Fact]
        public void ShouldGeneratePrintingOption()
        {
            var sut = new OptionsConsoleWriter();

            var mockPrintingToggle = new Mock<IFeatureToggle>();
            mockPrintingToggle.SetupGet(x => x.FeatureEnabled)
                              .Returns(true);

            string options = sut.Generate(mockPrintingToggle.Object);

            Assert.Contains("(p)rinting", options);
        }

        [Fact]
        public void ShouldNotGeneratePrintingOption()
        {
            var sut = new OptionsConsoleWriter();

            var mockPrintingToggle = new Mock<IFeatureToggle>();
            mockPrintingToggle.SetupGet(x => x.FeatureEnabled)
                              .Returns(false);

            string options = sut.Generate(mockPrintingToggle.Object);

            Assert.DoesNotContain("(p)rinting", options);
        }
    }
}

SHARE:

FeatureToggle v4 RC2 with .NET Core Configuration Changes

FeatureToggle logo

The pre-release RC2 version of FeatureToggle with .NET Core support is now available on NuGet.

See release notes and GitHub issues for additional background/breaking changes/limitations.

RC2 builds on RC1 and modifies the format of the json settings to make use of nesting as discussed in this issue, for example:

{
  "FeatureToggle": {
    "Printing": "true",
    "Saving": "false"
  }
}

Thanks to @steventmayer for the suggestions.

SHARE:

FeatureToggle v4 RC1 with .NET Core Support

The pre-release RC1 version of FeatureToggle with .NET Core support is now available on NuGet.

See release notes and GitHub issues for additional background/breaking changes/limitations.

The main drive for v4 is to add initial .NET Core support.

Using Feature Toggle in a .NET Core Console App

In Visual Studio 2017, create a new .NET Core Console App and install the NuGet package. This will also install the dependent FeatureToggle.NetStandard package (.NET Standard 1.4).

Add the following code to Program.cs:

using System;
using FeatureToggle;

namespace ConsoleApp1
{

    public class Printing : SimpleFeatureToggle { }
    public class Saving : EnabledOnOrAfterDateFeatureToggle { }
    public class Tweeting : EnabledOnOrAfterAssemblyVersionWhereToggleIsDefinedToggle { }

    class Program
    {
        static void Main(string[] args)
        {
            var p = new Printing();
            var s = new Saving();
            var t = new Tweeting();

            Console.WriteLine($"Printing is {(p.FeatureEnabled ? "on" : "off")}");
            Console.WriteLine($"Saving is {(s.FeatureEnabled ? "on" : "off")}");
            Console.WriteLine($"Tweeting is {(t.FeatureEnabled ? "on" : "off")}");


            Console.ReadLine();
        }
    }
}

Running the application will result in an exception due to missing appSettings.config file: “System.IO.FileNotFoundException: 'The configuration file 'appSettings.json' was not found and is not optional.“ By default, FeatureToggle will expect toggles to be configured in this file, add an appSettings.json and set its Copy To Output Directory to “Copy if newer” and add the following content:

{
  "FeatureToggle.Printing": "true",
  "FeatureToggle.Saving": "01-Jan-2014 18:00:00",
  "FeatureToggle.Tweeting": "2.5.0.1" // Assembly version is set to 2.5.0.0
}

Running the app now result in:

Printing is on
Saving is on
Tweeting is off

Using Feature Toggle in an ASP.NET Core App

Usage in an ASP.NET core app currently requires the configuration to be provided when instantiating a toggle, this may be cleaned up in future versions. For RC1 the following code shows the Startup class creating a FeatureToggle AppSettingsProviderand and passing it the IConfigurationRoot from the startup class.

public void ConfigureServices(IServiceCollection services)
{
    // Set provider config so file is read from content root path
    var provider = new AppSettingsProvider { Configuration = Configuration };

    services.AddSingleton(new Printing { ToggleValueProvider = provider });
    services.AddSingleton(new Saving { ToggleValueProvider = provider });

    // Add framework services.
    services.AddMvc();
}

The appSettings would look something like the following:

{
  "FeatureToggle.Printing": "true",
  "FeatureToggle.Saving": "false",
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Warning"
    }
  }
}

As an example of using this configuration check out the example project on GitHub, in particular the following:

https://github.com/jason-roberts/FeatureToggle/blob/master/src/Examples/AspDotNetCoreExample/Models/Printing.cs

https://github.com/jason-roberts/FeatureToggle/blob/master/src/Examples/AspDotNetCoreExample/Models/Saving.cs

https://github.com/jason-roberts/FeatureToggle/blob/master/src/Examples/AspDotNetCoreExample/ViewModels/HomeIndexViewModel.cs

https://github.com/jason-roberts/FeatureToggle/blob/master/src/Examples/AspDotNetCoreExample/Controllers/HomeController.cs

https://github.com/jason-roberts/FeatureToggle/blob/master/src/Examples/AspDotNetCoreExample/Views/Home/Index.cshtml

https://github.com/jason-roberts/FeatureToggle/blob/master/src/Examples/AspDotNetCoreExample/Startup.cs

https://github.com/jason-roberts/FeatureToggle/blob/master/src/Examples/AspDotNetCoreExample/appsettings.json

SHARE:

New FeatureToggle Release: v3.4 With Fluent Syntax

FeatureToggle is an open source feature toggling / feature switching library for .NET.

Version 3.4 Introduces an new additional way to get the value of whether a toggle is enabled or not.

In versions to v3.3 and earlier, to get the value of a toggle, an instance of the toggle class needed to be created manually:

new SampleFeatureToggle().FeatureEnabled

With v3.4 a new additional fluent way is introduced to improve readability and offer a convenience when evaluating a toggle.

First reference the FeatureToggle.Core.Fluent namespace, then the Is<T> class can be used as follows:

Is<SampleFeatureToggle>.Enabled
Is<SampleFeatureToggle>.Disabled

To make the fluent style a little more readable, the name of the concrete toggle class can be shorted, so rather than PrintFeatureToggle for example, it could be named Print, the code would then read:

Is<Printing>.Enabled
Is<Printing>.Disabled

SHARE:

FeatureToggle v3.3 Released

FeatureToggle is an open source feature toggling library for .NET.

Version 3.3 was just released to NuGet and includes two minor new features as described below.

FallbackValueDecorator

The FallbackValueDecorator allows you to wrap (decorate) a primary toggle and specific a fallback toggle to be used if the primary toggle fails or is not configured.

new FallbackValueDecorator(new MyPrimaryToggle(), new MyFallbackToggle());

An optional overload allows the specifying of an Action<Exception> to be called if the primary toggle errors for example to perform some logging or alerting:

public FallbackValueDecorator(IFeatureToggle primaryToggle, IFeatureToggle fallbackToggle, Action<Exception> logAction = null)

CompositeOrDecorator

The CompositeOrDecorator allows the specification of two toggle instances, if either one of the toggles is enabled the decorator will return true:

new CompositeOrDecorator(new AnEnabledFeature(), new ADisabledFeature());


If you’re new to the concept of feature toggling or FeatureToggle check out my Pluralsight course Implementing Feature Toggles in .NET with FeatureToggle or the documentation.


Thanks to Craig Vermeer for the work investigating failing convention tests in VS2015 for this release.

SHARE:

FeatureToggle 3.2 Released

FeatureToggle logo image

A minor release of my open source FeatureToggle library has just been released to NuGet.

Version 3.2 was a result of user requests to be able to configure toggles that get their values from sql server to be configured using the <connectionStrings> section of the .config file.

A Sql based toggle can now be configured a number of different ways

Using appSettings only

This is the original method:

<appSettings>
   <add key="FeatureToggle.SaveToPdfFeatureToggle.ConnectionString" value="Data Source=.\SQLEXPRESS;Initial Catalog=FeatureToggleDatabase;Integrated Security=True;Pooling=False"/>
   <add key="FeatureToggle.SaveToPdfFeatureToggle.SqlStatement" value="select Value from Toggle where ToggleName = 'SaveToPdfFeatureToggle'"/>
</appSettings>

Using connectionStrings Entry by Convention

<appSettings>
    <add key="FeatureToggle.SaveToPdfFeatureToggle.SqlStatement" value="select Value from Toggle where ToggleName = 'SaveToPdfFeatureToggle'"/>
</appSettings>

<connectionStrings>
    <add name="FeatureToggle.SaveToPdfFeatureToggle" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=FeatureToggleIntegrationTests;Integrated Security=True;Pooling=False" />    
</connectionStrings>

 

Using connectionStrings Custom Named Entry

This option allows multiple toggles to share a named connection if you have more than one sql toggle in the application.

<appSettings>
    <add key="FeatureToggle.SaveToPdfFeatureToggle.SqlStatement" value="select Value from Toggle where ToggleName = 'SaveToPdfFeatureToggle'"/>
    <add key="FeatureToggle.SaveToPdfFeatureToggle.ConnectionStringName" value="myAwesomeConnection" />
</appSettings>

<connectionStrings>
    <add name="myAwesomeConnection" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=FeatureToggleIntegrationTests;Integrated Security=True;Pooling=False" />    
</connectionStrings>

Thanks

Thanks to the following people for contributions and ideas:

SHARE: