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:

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: