My latest Pluralsight video training course was just published just in time for some holiday season learning! :)

From the description: “Releasing software to production can be hard, risky, and time-consuming, especially if there is a problem and you need to roll back the deployment. In this course, Feature Flags Fundamentals and Microsoft Feature Management, you’ll gain the ability to effectively and efficiently manage the development and deployment of features. First, you’ll explore how to configure and use feature flags in code. Next, you’ll discover how to control features and HTML rendering using Microsoft feature flags in an ASP.NET Core app. Finally, you’ll learn how to customize Microsoft Feature Management and even manage features from Azure. When you’re finished with this course, you’ll have the skills and knowledge of Microsoft Feature Management needed to effectively deploy and manage features in production.”

You can read more about the course over on the official course homepage. Or start watching with a free trial today.

SHARE:

This is part ten in a series of articles.

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

In part 4 we looked at creating custom feature filters and in part 5 we looked at configuring features with Azure App Configuration. We can combine these techniques to create a custom feature filter that we can configure remotely in Azure.

For example suppose we have the following class representing a custom feature filter that  enables a feature if a query string field is present:

[FilterAlias("BetaQueryString")]
public class BetaQueryStringFeatureFilter : IFeatureFilter
{
    private readonly IHttpContextAccessor _httpContextAccessor;
    
    public BetaQueryStringFeatureFilter(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor ?? throw new ArgumentNullException(nameof(httpContextAccessor));
    }

    public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
    {
        BetaQueryStringFeatureFilterSettings settings = context.Parameters.Get<BetaQueryStringFeatureFilterSettings>();           

        bool isEnabled = _httpContextAccessor.HttpContext.Request.Query.ContainsKey(settings.QueryStringFieldName);

        return Task.FromResult(isEnabled);
    }
}

The configurable parameters for this feature filter are represented by the following class:

public class BetaQueryStringFeatureFilterSettings
{
    public string QueryStringFieldName { get; set; }
}

In the appsettings.json we could configure a feature called “printing” to use this custom feature filter:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "BetaQueryString",
        "Parameters": {
          "QueryStringFieldName": "beta"
        }
      }
    ]
  }
}

Notice in the preceding config that the query string field that needs to be present in the request URL is the string “beta”. This means if the URL was something like “”http://localhost:5607/?beta” the printing feature would be enabled.

If we wanted to enable the filter when the URL query string contained a field called “earlyaccess” we could change the appsettings.config to:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "BetaQueryString",
        "Parameters": {
          "QueryStringFieldName": "earlyaccess"
        }
      }
    ]
  }
}

Configuring Custom Feature Filters with Azure App Config

Instead of having the query string field defined in the appsettings.config we could instead hold this value in Azure. Check out part 5 for more info on setting this up.

After configuring the web app to use Azure App Configuration for feature flag settings, we can modify the appsettings.json to remove the QueryStringFieldName parameter because this will now be coming from Azure:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "BetaQueryString"          
      }
    ]
  }
}

Setting up a custom/conditional feature filter in Azure App Configuration is a little unintuitive at the moment. After clicking Add and specifying the feature name (in this case “Printing”) you then need to click the On toggle and then click the  Add filter button.

Next, enter a key that matches the name of the custom feature filter, in this case “BetaQueryString” and then click the ellipses … and choose Edit parameters:

The name of the parameter should match what settings value the custom feature filter is looking for, in this case “QueryStringFieldName” and in the Value box enter the configured value you want, for example “beta” :

Click Apply and then Apply again and you should now see the Printing feature marked as conditional:

Now you can run the web app and remotely configure what query string parameter will enable the printing feature.

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

SHARE:

This is part nine in a series of articles.

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

One of the feature filters that Microsoft Provides is the targeting feature filter. This allows you to gradually rollout a feature to make sure it’s working for a small subset of users before rolling it out to everyone. This approach can help to find bugs that might have slipped into the feature during development. By not just turning on the feature for all users, you can shield them from any problems, only a few users will see the error.

At first glance the targeting feature filter might seem a bit confusing but essentially it allows you to expose the new feature to your “audience”. The “audience” are your users.

Your audience can be specified in 3 ways:

1. By specific user(s)
2. By which group(s) the current user belongs to
3. By a percentage of all users, regardless of 1 & 2 above

For example, you could release a new feature and only have it enabled for 1 or 2 specific users (e.g. Sarah and Amrit). These users could be part of the development team that have accounts setup in the production system. Sarah and Amrit will see the new feature and be able to check it is working, everyone else won’t see it.

Once Sarah and Amrit have used the new feature and are sure that there are no errors, the feature can be rolled out to a small subset of users. This subset is represented as a group. For example you could have a subset of users (that all belong to a group called “earlyadopters”) who have opted in to get access to “beta” features before other users. These users would be made aware at the time they opted in that they might experience some occasional errors. You could  enable the new feature for all “earlyadopters” or for a subset of them based on a percentage. For example you could start with 10% of early adopters and if there are no errors, gradually increase it to 100% of early adopters.

Once all early adopters are using the feature and there is confidence that the new feature is working correctly, the feature can be rolled out to all the other users. You could do this all at once, or once again start by rolling it out to 50% of them and gradually increase to 100%, or just go straight to 100% and enable for everyone.

Essentially, feature targeting gives you a great amount of control on how you roll out new features. Contrast this with just releasing a new feature to production with no feature flags and all users starting to use it at the same time. If there is a problem with the new feature, all users will will see it and be affected by it.

Using Feature Targeting

Create an ASP.NET Core 3.1 MVC app and create it with “individual user accounts” authentication. This will enable you to add users to local SQL database rather that relying on Windows auth for example.

The first thing to do is map users and groups in whatever authentication method is being used to users/groups in the Microsoft Feature Management world. Specifically to create TargetingContext instances for users. A TargetingContext contains the user id and list of groups to which the user belongs. This information is used to position the current user in the audience that has been configured.

One way to build a TargetingContext is to get it from the current HTTP context by getting the HttpContext.User property.

To create TargetingContexts, you can create a class that implements the Microsoft.FeatureManagement.FeatureFilters.ITargetingContextAccessor interface. This interface has a method GetContextAsync inside which you create a TargetingContext for the current user:

using System;
using Microsoft.AspNetCore.Http;
using Microsoft.FeatureManagement.FeatureFilters;
using System.Collections.Generic;
using System.Security.Claims;
using System.Threading.Tasks;

namespace WebApplication2.Models
{
    /// <summary>
    /// Based on https://github.com/microsoft/FeatureManagement-Dotnet/blob/master/examples/FeatureFlagDemo/HttpContextTargetingContextAccessor.cs
    /// </summary>
    public class HttpTargetingContextAccessor : ITargetingContextAccessor
    {
        private const string CacheKey = "HttpContextTargetingContextAccessor.TargetingContext";
        private readonly IHttpContextAccessor _httpContextAccessor;

        public HttpTargetingContextAccessor(IHttpContextAccessor httpContextAccessor)
        {
            _httpContextAccessor = httpContextAccessor ?? throw new ArgumentNullException(nameof(httpContextAccessor));
        }

        public ValueTask<TargetingContext> GetContextAsync()
        {
            HttpContext httpContext = _httpContextAccessor.HttpContext;

            if (ACachedTargetingContextExists())
            {
                return CachedTargetingContext();
            }

            ClaimsPrincipal user = httpContext.User;
            TargetingContext targetingContext = new TargetingContext
            {
                UserId = user.Identity.Name,
                Groups = GetGroupsFromClaims()
            };

            CacheTargetingContextForFutureLookups();

            return new ValueTask<TargetingContext>(targetingContext);

            // Local functions could be moved to class level functions
            bool ACachedTargetingContextExists() => httpContext.Items.ContainsKey(CacheKey);
           
            ValueTask<TargetingContext> CachedTargetingContext() =>  new ValueTask<TargetingContext>((TargetingContext)httpContext.Items[CacheKey]);
           
            IEnumerable<string> GetGroupsFromClaims()
            {                               
                // In this implementation groups/roles are specified using claims (ClaimTypes.Role)
                foreach (Claim claim in user.Claims)
                {
                    if (claim.Type == ClaimTypes.Role) 
                    {
                        yield return claim.Value;
                    }
                }
            }
          
            void CacheTargetingContextForFutureLookups() => httpContext.Items[CacheKey] = targetingContext;
        }
    }
}

In the preceding code, we are basically getting the user id of the current request and also any roles/groups to which that user belongs. This is in the form of a TargetingContext instance. This TargetingContext instance will be used by the targeting feature filter to decide whether or not to give the user access to the feature.

Configuring Targeting

To configure the targeting filter, you specify the users and/or groups, and the percentage of all users:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "Microsoft.Targeting",
        "Parameters": {
          "Audience": {
            "Users": [
              "Sarah",
              "Amrit"
            ],
            "Groups": [
              {
                "Name": "earlyadopters",
                "RolloutPercentage": 10
              }
            ],
            "DefaultRolloutPercentage": 0
          }
        }
      }
    ]
  }
}

In the preceding config, the Printing feature will be enabled for:

• Sarah and Amrit
• 10% of all users in the earlyadopters role/group
• 0% of all users

Once the feature has been running in production without error this could be expanded to all the early adopters:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "Microsoft.Targeting",
        "Parameters": {
          "Audience": {
            "Users": [
              "Sarah",
              "Amrit"
            ],
            "Groups": [
              {
                "Name": "earlyadopters",
                "RolloutPercentage": 100
              }
            ],
            "DefaultRolloutPercentage": 0
          }
        }
      }
    ]
  }
}

And then at a later point, 50% of non early adopters (i.e. 50% of the user base):

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "Microsoft.Targeting",
        "Parameters": {
          "Audience": {
            "Users": [
              "Sarah",
              "Amrit"
            ],
            "Groups": [
              {
                "Name": "earlyadopters",
                "RolloutPercentage": 100
              }
            ],
            "DefaultRolloutPercentage": 50
          }
        }
      }
    ]
  }
}

And then to everyone:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "Microsoft.Targeting",
        "Parameters": {
          "Audience": {
            "Users": [
              "Sarah",
              "Amrit"
            ],
            "Groups": [
              {
                "Name": "earlyadopters",
                "RolloutPercentage": 100
              }
            ],
            "DefaultRolloutPercentage": 100
          }
        }
      }
    ]
  }
}

Now once the feature has been used for enough time and is considered stable, in a future release the Printing feature flag and associated code can be removed from the app.

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

SHARE:

This is part eight in a series of articles.

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

In part six of this series, we saw how to prevent a feature flag from changing during processing of a single request.

In this article we’re going to look at how to maintain consistency across multiple requests for the same user/session.

The Problem

Consider the following scenario that introduces a feature flag MustCaptureAge. For example suppose new legal regulations require that from a certain date or time that the application must now capture the age of a customer for all purchases:

1. New age functionality is deployed to production with MustCaptureAge flag set to false
2. User 42 navigates to web app
3. User 42 adds an item to their cart
4. User 42 navigates to checkout
5. At this point MustCaptureAge=false so no Age input is displayed
6. User 42 starts typing information onto checkout page
7. Whilst User 42 is typing, MustCaptureAge flags gets set to true
8. User 42 clicks submit
9. What happens now? Age was not captured…

In the preceding scenario the MustCaptureAge feature flag changed between requests. At the start it was set to false but at some point during the user’s interaction it got set to true. This type of scenario could cause unpredictable results, legal breaches, data corruption, missed sales, annoyed customers, etc.

One way to fix this is to maintain the feature flag value across all requests for a given session, essentially taking the initial value of the feature flag and caching it for all subsequent requests in that session.

Preserving Feature Flag Values Across Multiple ASP.NET Core Requests

The ISessionManager interface in the Microsoft.FeatureManagement namespace allows the implementer to store the state of feature flags for a session. This interface is not specific to ASP.NET and can be used in non web-applications. It also has no dependency on HTTP context. We can however implement a version that can be used in an ASP.NET Core web app.

The interface has 2 methods to get and set the value of a feature flag. Inside these methods we can make use of the current HTTP session context to store the feature flag value. Essentially the first time the feature flag is looked up for a session, its value will be persisted in session state for the remainder of the session, even across multiple pages/requests.

As an example, the following code shows a basic implementation that uses an IHttpContextAccessor to get access to the HttpContext of the current request and then store or retrieve the value in ASP.NET session state:

using Microsoft.AspNetCore.Http;
using Microsoft.FeatureManagement;
using System;
using System.Threading.Tasks;

namespace WebApplication1.Models
{
    /// <summary>
    /// Based on https://andrewlock.net/keeping-consistent-feature-flags-across-requests-adding-feature-flags-to-an-asp-net-core-app-part-5/
    /// </summary>
    public class HttpContextFeatureSessionManager : ISessionManager
    {
        private readonly IHttpContextAccessor _contextAccessor;
        private const string SessionKeyPrefix = "feature_flag_";
       
        public HttpContextFeatureSessionManager(IHttpContextAccessor contextAccessor)
        {
            _contextAccessor = contextAccessor;
        }

        public Task<bool?> GetAsync(string featureName)
        {
            bool keyExistsInHttpSession = _contextAccessor.HttpContext
                                                          .Session
                                                          .TryGetValue(key: $"{SessionKeyPrefix}{featureName}",
                                                                       value: out byte[] bytes);

            if (keyExistsInHttpSession)
            {
                return Task.FromResult((bool?)BitConverter.ToBoolean(bytes));
            }

            return Task.FromResult<bool?>(null);
        }

        public Task SetAsync(string featureName, bool enabled)
        {            
            _contextAccessor.HttpContext
                            .Session
                            .Set(key: $"{SessionKeyPrefix}{featureName}", 
                                 value: BitConverter.GetBytes(enabled));
            
            return Task.CompletedTask;
        }
    }
}

To plug the above HttpContextFeatureSessionManager into the ASP.NET Core app, modify the Startup.ConfigureServices method and add services.AddTransient<ISessionManager, HttpContextFeatureSessionManager>(); and to enable session state: services.AddSession(); You’ll also need to add app.UseSession(); in the Configure method:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.FeatureManagement;
using WebApplication1.Models;

namespace WebApplication1
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddSession();
            services.AddTransient<ISessionManager, HttpContextFeatureSessionManager>();
            services.AddControllersWithViews();            
            services.AddHttpContextAccessor();
            services.AddFeatureManagement();
        }

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            app.UseSession();

            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Home/Error");
            }
            app.UseStaticFiles();

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllerRoute(
                    name: "default",
                    pattern: "{controller=Home}/{action=Index}/{id?}");
            });            
        }
    }
}

In the appsettings.json, we can configure the MustCaptureAge feature:

"FeatureManagement": {
  "MustCaptureAge": true
}

And then for example use it in the UI:

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <feature name="MustCaptureAge">
        <label for="age">Please enter your age</label>
        <input name="age" type="number"/>
    </feature>    
</div>

Now if we run the app, the page will load and show the age input because MustCaptureAge is set to true. However,  if we now modify the appsettings.json and change MustCaptureAge to “false” while the web app is still running,  and save the file, the existing session that’s open in the browser will still show the age input. If however we open another session (e.g. in another browser) the age input will not be shown.

There are however a number of problems with the HttpContextFeatureSessionManager implementation. We might want only some features to be preserved across requests but other features to be updated immediately regardless of if a session is currently underway.

One way to opt in, if using strongly typed feature names via an enum (see part two) is to define a custom attribute:

using System;

namespace WebApplication1.Models
{
    public sealed class PreserveFeatureAttribute : Attribute { }
}

And then decorate any enum value feature flags that you want to preserve across requests:

public enum Features
{
    Printing,
    [PreserveFeature]
    MustCaptureAge
}

In the preceding enum, the Printing feature will not be preserved for a session, but the MustCaptureAge feature will be consistent for requests in a single session.

To make use of this attribute, the HttpContextFeatureSessionManager can be modified. Using some reflection code (which may not be the fastest as it will be performed on every request) we can examine whether or not the enum value has the attribute and only set the session item if it does:

using Microsoft.AspNetCore.Http;
using Microsoft.FeatureManagement;
using System;
using System.Linq;
using System.Reflection;
using System.Threading.Tasks;

namespace WebApplication1.Models
{
    /// <summary>
    /// Based on https://andrewlock.net/keeping-consistent-feature-flags-across-requests-adding-feature-flags-to-an-asp-net-core-app-part-5/
    /// </summary>
    public class HttpContextFeatureSessionManager : ISessionManager
    {
        private readonly IHttpContextAccessor _contextAccessor;
        private const string SessionKeyPrefix = "feature_flag_";
       
        public HttpContextFeatureSessionManager(IHttpContextAccessor contextAccessor)
        {
            _contextAccessor = contextAccessor;
        }

        public Task<bool?> GetAsync(string featureName)
        {
            bool keyExistsInHttpSession = _contextAccessor.HttpContext
                                                          .Session
                                                          .TryGetValue(key: $"{SessionKeyPrefix}{featureName}",
                                                                       value: out byte[] bytes);

            if (keyExistsInHttpSession)
            {
                return Task.FromResult((bool?)BitConverter.ToBoolean(bytes));
            }

            return Task.FromResult<bool?>(null);
        }

        public Task SetAsync(string featureName, bool enabled)
        {
            if (!ShouldPreserveAccrossRequests(featureName))
            {
                return Task.CompletedTask;
            }

            _contextAccessor.HttpContext
                            .Session
                            .Set(key: $"{SessionKeyPrefix}{featureName}", 
                                 value: BitConverter.GetBytes(enabled));
            
            return Task.CompletedTask;
        }

        private static bool ShouldPreserveAccrossRequests(string featureName)
        {        
            MemberInfo enumFieldInfo = typeof(Features).GetMember(featureName).First();            
                        
            if (enumFieldInfo.GetCustomAttributes(typeof(PreserveFeatureAttribute), false).Any())
            {
                return true;
            }

            return false;
        }
    }
}

Now if we have the following in the view:

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <feature name="MustCaptureAge">
        <label for="age">Please enter your age</label>
        <input name="age" type="number" />
    </feature>
    <feature name="Printing">        
        <button>Print</button>
    </feature>
</div>

The print button can change for different requests in a single session, whereas the age input will never change within a single session.

This reflection based approach also means that the configuring is hard coded into the enum. You could however read session preservation settings from configuration.

Another disadvantage of this approach is when you are using feature filters. A simple true/false feature flag is less complex than a percentage filter or a date range based feature. For example what if a feature is set to turn on automatically by using the Time Window Feature Filter, the feature could automatically turn on during a session, should the current date/time be honoured or should the date/time from the first initial session request be honoured? This is as much a business consideration as it is a technical one and there is no one right answer.

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

SHARE:

This is part seven in a series of articles.

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

You can render HTML in your views based on whether or not a feature flag is enable or disabled. To do this you can make use of the FeatureTagHelper.

For example suppose the following Printing feature is configured to be off in the appsettings.json:

"FeatureManagement": {
  "Printing": false    
}

Now in the view (or _ViewImports.cshtml) you can add the tag helper and then use the <feature> tag:

@addTagHelper *, Microsoft.FeatureManagement.AspNetCore

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <feature name="Printing">
        <button>Print</button>
    </feature>
</div>

Notice in the preceding view that the <feature> tag has the  name property set to the feature set in config, i.e. “Printing”.

If you have defined your features in an enum as described earlier in this series, you could use a nameof expression instead:

@addTagHelper *, Microsoft.FeatureManagement.AspNetCore

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <feature name="@nameof(Features.Printing)">
        <button>Print</button>
    </feature>
</div>

The FeatureTagHelper has a number of ways it can be used. For example you can invert the configured feature value by setting the negate property to true:

@addTagHelper *, Microsoft.FeatureManagement.AspNetCore

    <div class="text-center">
        <h1 class="display-4">Welcome</h1>
        <feature name="@nameof(Features.Printing)">
            <button>Print</button>
        </feature>
        <feature name="@nameof(Features.Printing)" negate="true">
            <button disabled>Printing is disabled</button>
        </feature>
    </div>

The preceding view will show a disabled button when the printing feature is not available.

You can also specify multiple features in a single <feature> name:

<feature name="Printing, PrintPreview">
    <button>Print</button>
</feature>

Notice in the preceding view that both the Printing and PrintPreview features are used (comma separated) in the name attribute. By default this is a logical AND so both features need to be enabled for the contents of the <feature> tag to be rendered, e.g.:

"FeatureManagement": {
  "Printing": true,
  "PrintPreview": true
}

If you want to use a logical OR and render the HTML when any of the specified features are enabled you can set the requirement attribute to “Any”:

@addTagHelper *, Microsoft.FeatureManagement.AspNetCore

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <feature name="Printing, PrintPreview" requirement="Any">
        <button>Print</button>
    </feature>
</div>

Now if either (or both) Printing or PrintPreview is enabled the button will be rendered.

You could also implement a more strongly typed tag helper that uses a Features enum to represent the features:

public enum Features
{
    Printing,
    PrintPreview,
    QuickQuotes,
    OnlineChat
}

using Microsoft.AspNetCore.Razor.TagHelpers;
using Microsoft.FeatureManagement;
using System.Threading.Tasks;

namespace WebApplication1.Models
{
    /// <summary>
    /// Based on https://github.com/microsoft/FeatureManagement-Dotnet/blob/master/src/Microsoft.FeatureManagement.AspNetCore/TagHelpers/FeatureTagHelper.cs
    /// </summary>    
    public class FeatureTagHelper : TagHelper
    {
        private readonly IFeatureManager _featureManager;

        public Features Feature { get; set; }
        
        public FeatureTagHelper(IFeatureManagerSnapshot featureManager)
        {
            _featureManager = featureManager;
        }

        public override async Task ProcessAsync(TagHelperContext context, TagHelperOutput output)
        {
            DontOutputTagName();

            bool isFeatureEnabled = await _featureManager.IsEnabledAsync(Feature.ToString()).ConfigureAwait(false);

            if (!isFeatureEnabled)
            {
                output.SuppressOutput();
            }

            void DontOutputTagName() => output.TagName = null;
        }
    }
}

@addTagHelper *, WebApplication1

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <feature feature="@Features.Printing">
        <button>Print</button>
    </feature>
</div>

You could also go one step further and define a tag helper for every feature:

using Microsoft.AspNetCore.Razor.TagHelpers;
using Microsoft.FeatureManagement;
using System.Threading.Tasks;

namespace WebApplication1.Models
{
    /// <summary>
    /// Based on https://github.com/microsoft/FeatureManagement-Dotnet/blob/master/src/Microsoft.FeatureManagement.AspNetCore/TagHelpers/FeatureTagHelper.cs
    /// </summary>    
    public abstract class FeatureTagHelper : TagHelper
    {
        private readonly IFeatureManager _featureManager;

        protected Features _feature;
        
        public FeatureTagHelper(IFeatureManagerSnapshot featureManager, Features feature)
        {
            _featureManager = featureManager;
            _feature = feature;
        }

        public override async Task ProcessAsync(TagHelperContext context, TagHelperOutput output)
        {
            DontOutputTagName();

            bool isFeatureEnabled = await _featureManager.IsEnabledAsync(_feature.ToString()).ConfigureAwait(false);

            if (!isFeatureEnabled)
            {
                output.SuppressOutput();
            }

            void DontOutputTagName() => output.TagName = null;
        }
    }

    public class PrintingTagHelper : FeatureTagHelper
    {
        public PrintingTagHelper(IFeatureManagerSnapshot featureManager) : base(featureManager, Features.Printing) {}        
    }

    public class OnlineChatTagHelper : FeatureTagHelper
    {
        public OnlineChatTagHelper(IFeatureManagerSnapshot featureManager) : base(featureManager, Features.OnlineChat) {}
    }
}

@addTagHelper *, WebApplication1

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <printing>
        <button>Print</button>
    </printing>
    <online-chat>
        <button>chat</button>
    </online-chat>
</div>

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

SHARE:

This is part six in a series of articles.

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

If you check a feature flag multiple times during a single HTTP request in ASP.NET Core, the feature can return a different results for each check.

For example, the Microsoft.Percentage feature filter which we looked at in part three enables a feature for a specified percentage of feature checks:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "Microsoft.Percentage",
        "Parameters": {
          "Value": 50
        }
      }
    ]
  }
}

If, within a single HTTP request, the printing feature is queried you will get different results. The following is a simple demo of this:

public async Task<IActionResult> Index()
{
    CheckPrintingFeature();
    CheckPrintingFeature();
    CheckPrintingFeature();

    return View();            

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

If we run the web app, the ViewData could be set to “Off, Off, On,” for example. This means if you are controlling which version of an algorithm gets used based on a feature flag and you are doing this in multiple places within a single HTTP request you may get different versions of the algorithm used, which is probably not what you want. This behaviour is not limited to the Percentage feature filter.

Using Feature Flag Snapshots During a Single Request

Luckily the FeatureManagement team has thought of this and provides an alternative in the form of the IFeatureManagerSnapshot interface. This interface represents a “a snapshot of feature state to ensure consistency across a given request” [Microsoft]. This means that within a single request, the first time a feature is checked, the result will be remembered for all subsequent checks within that HTTP request.

To use this, instead of injecting an IFeatureManager into a controller, you can instead inject an IFeatureManagerSnapshot:

private IFeatureManagerSnapshot _featureManager;

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

If you run the app now, you’ll get a message of either “Off, Off, Off,” or “On, On, On,”, you won’t get mixed results within a single request. You may still get different results across multiple requests, even for the same user/session. In a future post we’ll look at preserving values across requests.

Interestingly the <feature> tag helper internally uses IFeatureManagerSnapshot – this means that if you are controlling UI elements with the tag helper then you will get consistent results within a single request, for example:

<ul>
    <feature name="Printing">
        <li>Tag helper check 1</li>
    </feature>
    <feature name="Printing">
        <li>Tag helper check 2</li>
    </feature>
    <feature name="Printing">
        <li>Tag helper check 3</li>
    </feature>
    <feature name="Printing">
        <li>Tag helper check 4</li>
    </feature>
    <feature name="Printing">
        <li>Tag helper check 5</li>
    </feature>
    <feature name="Printing">
        <li>Tag helper check 6</li>
    </feature>
    <feature name="Printing">
        <li>Tag helper check 7</li>
    </feature>
</ul>

The above will either show all <li>s or none at all.

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

SHARE:

This is part five in a series of articles.

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

So far in this series the feature flags in the application have been managed via the appsettings.json file, for example:

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

This means that if you want to manually enable a feature you need to update the config file manually in production or release a new version to production with the changed config file. If you want to manage feature flags without needing to modify the running production app/config one thing you could do is to create a custom feature filter to read from a database or API that’s external to your app.

As an alternative you could use Azure App Configuration to manage your features. This enables you to turn features on or off whenever you want.

Creating an Azure App Configuration Store

The first thing to do is sign in to Azure or create a free account.

Once in the Azure Portal, click the Create a resource button, and search for App Configuration:

Click the Create button.

Next, configure your App Configuration store, for example:

Notice in the preceding screenshot that I’ve selected the Pricing tier as Free which comes with a number of limitations such as no SLA, etc. – there is also the Standard tier which comes with 99.9% availability SLA, more requests, etc.

Once you’ve configured the new store, click Create. This will submit the deployments, you may have to wait a short while and then if you head to All Resources in the portal you should see your new store listed - click on it an then choose Feature manager:

It’s here you can add the names of your feature flags.

For example let’s add a feature flag to control printing in the app. Click the Add button, choose Off or On, give the feature a name (key) of “Printing”, and a description of “Print preview features”:

Click Apply.

You now have a Printing feature flag, the  next thing is to use it in an app.

Using Azure App Configuration Feature Flags in ASP.NET Core

In an ASP.NET Core app, add the following NuGet packages:

• Microsoft.FeatureManagement.AspNetCore
• Microsoft.Azure.AppConfiguration.AspNetCore

Next add a new connection string in the appsettings.json file called “AppConfig”. The connection can be found in the Azure portal by clicking on Access Keys and then clicking the copy to clipboard button next to the connection string:

Paste this connection string into the appsettings.json, for example:

{
  "ConnectionStrings": {
    "AppConfig": "Endpoint=https://msfeatureflagdemo.azconfig.io;Id=REDACTED"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*"
}

Note: you should be careful when adding secrets to config files that they are not accidentally checked in to source control or otherwise compromised. You should not have production passwords, secrets, etc checked into source control. One way to manage secrets in development to use the Secret Manager.

The next step is to modify the ASP.NET Core app to look for feature flags in Azure App Configuration.

First, modify the program.cs CreateHostBuilder method to add Azure App Configuration support:

public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
    .ConfigureWebHostDefaults(webBuilder =>
    {
        webBuilder.ConfigureAppConfiguration((hostingContext, config) =>
        {
            var settings = config.Build();
            config.AddAzureAppConfiguration(options =>
            {
                options.Connect(settings["ConnectionStrings:AppConfig"])
                    .UseFeatureFlags();
            });
        });

        webBuilder.UseStartup<Startup>();
    });
}

Notice in the preceding code that we are calling AddAzureAppConfiguration and then making sure that .UseFeatureFlags() is called.

Next in the Startup.Configuration method, add feature management:

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

    services.TryAddSingleton<IHttpContextAccessor, HttpContextAccessor>();

    services.AddFeatureManagement();
}

Turning Feature Flags Off and On with Azure App Configuration

Now in the app we can reference the Printing feature. In part one of this series we saw the feature tag helper, for example to hide a menu item based on a Printing feature 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>

Note: You should not rely solely on UI elements to “hide” features, you should also control them at the controller/action level with the [FeatureGate] attribute otherwise the action/URL will still be accessible even if the UI is not showing the menu item for example..

If you run the app now the printing menu item will not be shown because the Printing feature is currently off in Azure App Configuration:

If you click the On toggle, the feature will now be set to enabled. If you refresh the browser window you will notice however that the printing menu item is still not shown. However if you stop the web app and restart it the printing menu will now be shown.

To enable “live” updating of feature flags in ASP.NET Core you need to add an extra piece of middleware, to do this modify the Startup.Configure method and add app.UseAzureAppConfiguration();

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseAzureAppConfiguration();

    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
    }
    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllerRoute(
            name: "default",
            pattern: "{controller=Home}/{action=Index}/{id?}");
    });            
}

If you run the web app now and turn the feature off and on, if you refresh the browser a few times you should see the print menu item appear/disappear without needing to stop and start the web app. You may need to refresh several times before the feature flag setting is updated, this means that if you need to turn a feature off in an emergency situation it may not take effect immediately and you may still get users using the feature for a short while after making the change.

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

SHARE:

This is part four in a series of articles.

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

In part three I introduced the concept of feature filters. These allow features to be enabled/disabled based on more than a simple true/false configuration.

Currently there are 2 feature filters supplied out of the box, a percentage filter and a time window feature. You can also create you own custom feature filters.

Creating a Simple Custom Feature Filter

To create a custom feature filter, the first thing to do is create a new class, for example called “RandomFeatureFilter”. To create a feature filter you need to implement the IFeatureFilter interface from the Microsoft.FeatureManagement namespace. This interface has a single method called EvaluateAsync that returns a boolean result as a task. If this method returns true then the feature will be enabled. For example the following code implements a feature filter that will enable a feature at “random”:

using System;
using System.Threading.Tasks;
using Microsoft.FeatureManagement;

namespace WebApplication1.CustomFeatures
{
    public class RandomFeatureFilter : IFeatureFilter
    {
        public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
        {
            // Simple/ naive "random" implementation
            bool isEnabled = DateTime.Now.Ticks % 2 == 0;

            return Task.FromResult(isEnabled);
        }
    }
}

The next thing do do is register this custom feature filter when the app starts up, for example in an ASP.NET Core app:

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

    services.AddFeatureManagement()
            .AddFeatureFilter<WebApplication1.CustomFeatures.RandomFeatureFilter>();
}

The next step is to configure one or more features to get their status from the custom filter. To do this in the appsettings.json:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "RandomFeature"
      }
    ]
  }    
}

Notice in the preceding config that the filter is referred to by name as “RandomFeature” even though the class is called “RandomFeatureFilter” – notice the “Filter” suffix is removed.

Also note that if you try and specify the fully qualified class name ”WebApplication1.CustomFeatures.RandomFeatureFilter” or ”WebApplication1.CustomFeatures.RandomFeature” you’ll get an error.

Specifying a Feature Filter Alias

Instead of using the class name (minus any “filter” suffix) you can also specify a custom name/alias by decorating the filter class with the [FilterAlias] attribute as follows:

[FilterAlias("RandomizeFeatureFilter")]
public class RandomFeatureFilter : IFeatureFilter
{
    public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
    {
        // Simple/ naive "random" implementation
        bool isEnabled = DateTime.Now.Ticks % 2 == 0;

        return Task.FromResult(isEnabled);
    }
}

Now the configuration can change to:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "RandomizeFeatureFilter"
      }
    ]
  }    
}

Notice in the preceding config that when using an alias that the “filter” suffix is not removed.

Custom Feature Filter Configuration Parameters

If you want to pass additional configuration information to a feature filter you can do this. For example take the following config that allows you to specify a method of “randomness” of odd or even:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "RandomizeFeatureFilter",
        "Parameters": {
          "Method":  "Even"
        }
      }
    ]
  }    
}

To access this in the feature filter evaluation logic, a strongly typed settings class can first be created to represent the settings:

public class RandomFeatureFilterSettings
{
    public string Method { get; set; }
}

Notice in the preceding code that the property Method maps to the “Method” parameter in the appsetting.json. Also note that the property has a setter, if you only add a get then the property will always be null.

To get access to the config you can access the Parameters property of the FeatureFilterEvaluationContext that’s passed into the EvaluateAsync method:

[FilterAlias("RandomizeFeatureFilter")]
public class RandomFeatureFilter : IFeatureFilter
{
    public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
    {
        RandomFeatureFilterSettings settings = context.Parameters.Get<RandomFeatureFilterSettings>();

        if (settings.Method == "Even")
        {
            return Task.FromResult(DateTime.Now.Ticks % 2 == 0);
        }

        if (settings.Method == "Odd")
        {
            return Task.FromResult(DateTime.Now.Ticks % 2 != 0);
        }

        throw new Exception($"Random feature filter configured value '{settings.Method}' is invalid, must be 'Even' or 'Odd'.");
    }
}

Custom Feature Filters Based On HttpContext

You can also create a feature filter that uses information about the current HttpContext to decide whether or not to enable a feature.

For example we could create a feature filter to enable a feature or set of features when the cookie “beta” is present - for example to allow users to opt in to experimental features.

To do this, the first thing to do is create a feature filter class that has a constructor that takes an IHttpContextAccessor.This will be supplied in ASP.NET Core via dependency injection. This instance can be captured in a field and used in the EvaluateAsync method to access cookie information:

using System;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Http;
using Microsoft.FeatureManagement;

namespace WebApplication1.CustomFeatures
{
    [FilterAlias("BetaCookie")]
    public class BetaCookieFeatureFilter : IFeatureFilter
    {
        private readonly IHttpContextAccessor _httpContextAccessor;
        
        public BetaCookieFeatureFilter(IHttpContextAccessor httpContextAccessor)
        {
            _httpContextAccessor = httpContextAccessor ?? throw new ArgumentNullException(nameof(httpContextAccessor));
        }

        public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
        {
            bool isEnabled = _httpContextAccessor.HttpContext.Request.Cookies.ContainsKey("beta");

            return Task.FromResult(isEnabled);
        }
    }
}

To register IHttpContextAccessor in the Startup.ConfigureServices method:

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

    services.TryAddSingleton<IHttpContextAccessor, HttpContextAccessor>();

    services.AddFeatureManagement()
            .AddFeatureFilter<WebApplication1.CustomFeatures.BetaCookieFeatureFilter>();
}

The final thing to do is configure a feature flag to use this new BetaCookie feature filter:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "BetaCookie"
      }
    ]
  }    
}

Now when a cookie called “beta” is present, the Printing feature will be enabled, otherwise it will be disabled.

Feature filters are a powerful way of providing custom logic that is also configurable. For example we could generalize the BetaCookie filter to be something like CookiePresentFeatureFilter and then add a configuration parameter that allows us to specify the cookie name.

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

SHARE:

This is the third part in a series.

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

So far in this series, the configured feature flags have either been set to on (true) or off (false):

"FeatureManagement": {
  "Printing": true,
  "LiveChat": false
}

In addition to setting an absolute value, you can also make use of feature filters.

Essentially feature filters allow you to create conditional feature flags.

There are currently two feature filters built into the library and you can also create your own.

Percentage Feature Filter

If you want a feature enabled only for a percentage of users you can apply the Microsoft.Percentage feature filter.

To configure a feature filter in appsettings.json, instead of specifying a value of true/false, instead you add an EnabledFor section. For example to configure the Printing feature to be enabled 50% of the time:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "FeatureManagement": {
    "Printing": {
      "EnabledFor": [
        {
          "Name": "Microsoft.Percentage",
          "Parameters": {
            "Value": 50
          }
        }
      ]
    },
    "LiveChat": false
  }
}

If you run the app now  you’ll get an error because feature filters have to be registered. In an ASP.NET Core app this can be done by chaining on the AddFeatureFilter method, for example in the Startup.cs  as follows:

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

    services.AddFeatureManagement()
            .AddFeatureFilter<PercentageFilter>();
}

To get access to the PercentageFilter you’ll need to add a using directive for Microsoft.FeatureManagement.FeatureFilters.

Now if you run the app (e.g. an ASP.NET Core web app) the printing feature will be available for 50% of requests.

Time Window Feature Filter

The second built-in feature filter, Microsoft.TimeWindow, allows a feature to be enabled for a specified range of time.

The first thing is to register the feature filter:

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

    services.AddFeatureManagement()
            .AddFeatureFilter<TimeWindowFilter>();
}

Next the configuration can be changed.

The time window feature filter accepts two parameters in the config, a Start date/time and an End date/time, for example the following feature would be enabled at 1 second past midnight for New Year’s Day 2021 and be disable at the end of the 1st Jan:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "FeatureManagement": {
    "Printing": {
      "EnabledFor": [
        {
          "Name": "Microsoft.TimeWindow",
          "Parameters": {
            "Start": "Fri, 01 Jan 2021 00:00:01 GMT",
            "End": "Fri, 01 Jan 2021 23:59:59 GMT"
          }
        }
      ]
    },
    "LiveChat": false
  }
}

You can also specify that a feature should be enable after a specific date/time forever after by not specifying an end date, for example to enable a feature from the 1st may 2020, 1PM GMT:

"FeatureManagement": {
"Printing": {
  "EnabledFor": [
    {
      "Name": "Microsoft.TimeWindow",
      "Parameters": {
        "Start": "Fri, 01 May 2020 13:00:00 GMT"            
      }
    }
  ]
},

If you want a feature to be on until a date/time and then be off after that then you can just specify the end date, for example to have a feature enabled and then automatically turn off 5:10 AM on 15th may 2020:

"FeatureManagement": {
"Printing": {
  "EnabledFor": [
    {
      "Name": "Microsoft.TimeWindow",
      "Parameters": {
        "End": "Fri, 15 May 2020 05:10:00 GMT"
      }
    }
  ]
},

There is another advanced type of feature filtering called “targeting” that can be used to roll out new features based on a complex set of rules – I’ll cover this in a future part of this series.

You can also define your own feature filters which we’ll look at in the next part in this series.

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

SHARE:

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: