Any feature toggling solution we used needed satify a number of requirements. Most importantly the toggles must be accessible in any project within the parent .NET solution and must be configurable for each environment. E.g. On in your testing environment, off in live. In addition I wanted to make it as easy as possible to remove the toggles. That being the case I wanted each toggle to be defined in a single location that when deleted would cause build failures until all references to the toggle were removed. Finally I wanted an implementation where toggles could be used in the view, controller and model and would not break any unit tests.
The first step is to create a new web.config file to hold the toggles. Why a seperate file? This way web.configs from each project where the toggles are to be used can refer to this one file. I called my file featureToggles.config. This file can be used to store simple boolean appSettings which define whether the toggle is on or off.
<add key="MyFeatureToggle" value="true" />
When the featureToggle.config file is created, if you're using .NET 4, config transforms will automatically be created for you. They are required for this particular solution. If you're using .NET 3.5 or below you'll have to find another way to handle the transforms, sorry. Add a transform value for each environment. For instance my live transform might look like this:
<add key="MyFeatureToggle" value="false" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
How are the new appSettings loaded when they aren't included in the web.config file? One of my colleagues helped with that. The file attribute of the appSettings element allows you to specify a file which contains extra appSettings. So for whichever projects in your solution need to use the feature toggle simply add a reference to it in the appSettings element. For example our solution contains two web projects both of which require use of the feature toggles, so their appSettings elements would look something like this:
It's worth noting that if you are automating your builds using something like MSBuild you will need to add an extra step to apply the appropriate transform to the new featureToggles.config. I'm not going to go into the details here but if you want more information this post should help.
The next step is to get the appSettings values out of the config file. To do this I created a static class:
public static bool MultipleCards()
return ConfigurationManager.AppSettings["MyFeatureToggle"] != null
&& ConfigurationManager.AppSettings["MyFeatureToggle"].ToLower() == "true";
This the single place in code where the feature toggle is defined. If you want to remove the feature toggle simply delete the appropriate method from the static class and clean up the build errors. Why a static class? Because it can be used very easily in areas you aren't worried about unit testing. E.g. Views. What about using feature toggles in your model where introducing a static class would break unit tests? For that purpose I created a wrapper round the static class:
public bool MyFeatureToggle()
<%--Link to some awesome new feature--%>
<% } %>
// New code
// Old code