DEV Community: &ladeak

Using NDepend to improve my Application Code

&ladeak — Thu, 18 Jan 2024 08:00:00 +0000

Using NDepend to improve my Application

NDepend is a .NET code quality tool that performs static code analysis. It can help to detect code smells and dependency issues. In this post I will take a quick look at using the Dependency Graph feature to clean up one of my open-source applications. NDepend has a desktop application (as well as Visual Studio extension) that can be used by developers in a tight development cycle to address dependency and code quality issues during development:

change code
build application
run analysis (or configure automatic analysis in NDepend for every build)

The tool also comes with a handy console application that can be leveraged for enforce quality rules on CI/CD agents. Later in this post I look at generating reports with the NDepend Console on build agents.

Dependency Graph

Dependency Graph is a tool that can visualize dependencies of application components and identify common issues, such as cycles. I use this tool to re-organize C# classes and to fix namespace declarations in my project. To get started I set up an NDepend project using the desktop application VisualNDepend.exe. In the project properties select the dll-s to be included in the project analysis.

Note that the NDepend project file can be submitted to source control, so that a common rule set can be shared across the development team.

I leave the rest of the settings as default, and I use the green play button to Run Analysis. The initial analysis shows a dashboard with issues, quality gate violations and debt. In a tight development cycle a developer can track the trend of metrics or compare them with a known baseline. NDepend stores a single report for each day that is used for visualizing long term trends.

Navigate to Dependency Graph tab to visualize the application map:

It is instantly visible that my dependencies are less than ideal. The red edges with an arrow on both ends indicate cycles in across application components. One of the edges indicate that CHttp.Abstractions should not reference the CHttp.Statistics:

At this point I could search all classes to explore which causes the dependency cycle. However, there is a quicker way with NDepend. Right click on the edge and select Open this dependency on Matrix. This opens a Structure Matrix with the types in the scope of the target namespaces:

The blue and green squares show the dependencies between classes. It is immediately visible that the green squares indicate the undesired dependencies.

In the next step I refactor the code and repeat the above cycle. After many iterations I resolve all dependency violations resulting a conflict free dependency graph:

During this process I realized a few ideas that helped to become more productive:

Instead of jumping on the first dependency violation it is better to first outline the desired application structure. Then iterate the analysis, build, refactoring steps until the wanted architecture is achieved.
The tool performs a static analysis on the build output of the C# compiler. This means that unused using statements or trimmed code might not be reflected on the diagram.

Setting up Code Coverage analysis

Next step could be setting up code coverage analysis. In the desktop NDepend application a developer can add coverage files in Project Properties -> Analysis -> Code Coverage -> Settings window. NDepend handles opencover coverage format.

To setup Open Cover I add the coverage.collector nuget package. Then create a runsettings file, that specifies the format to be opencover and defines the excluded files:

<?xml version="1.0" encoding="utf-8" ?>
<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <DataCollector friendlyName="XPlat Code Coverage">
        <Configuration>
          <Format>opencover</Format>
          <ExcludeByFile>**/test/**/*.cs</ExcludeByFile>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

Run dotnet test command passing the runsettings file as settings to execute the tests and generate the test coverage:

dotnet test --settings mysettings.runsettings

The above command prints the test results and the test coverage file path to the console:

Passed!  - Failed:     0, Passed:    97, Skipped:     0, Total:    97, Duration: 7 s - CHttp.Tests.dll (net8.0)

Attachments:
  D:\repos\Http3Tools\tests\CHttp.Tests\TestResults\9e0687e7-8f5b-4673-a684-0cc969035a29\coverage.opencover.xml

The filename reflects that the generated report is indeed in opencover format. The containing folder path with file filter should be specified in the NDepend project. Re-running the analysis includes the Coverage report on the dashboard:

NDepend Reports

When selecting the Run Analysis and Build Report command in the desktop application, a set of HTML report files are generated. These reports can be viewed in a browser and hosted as static content on server.

A neat feature of these report files is that under issues tab one can navigate to the individual files to explore issues commented on the source code including the code coverage. It does not require a direct link to the source code, as these files are generated during the analysis.

NDepend Console

A careful reader might have realized that the HMTL file reports could be generated and shared by a build machine, so that a development team can review and act-up on them for every pull-request. However, the desktop NDepend application is a .NET Framework application that cannot run on a Linux build machine. Fortunately, NDepend comes with a cross-platform console application that can be used for the purpose. After registering the build machine license with the /RegLic switch a Continuous Integration (CI) job can be extended to invoke the console application to generate the reports for a given NDepend project:

dotnet NDepend.Console.MultiOS.dll D:\repos\Http3Tools\ndepend\NDepend.ndproj /ViewReport

The static report files can be typically served by the build agent as artifacts. There is no need for setting up and maintaining separate code quality services. Even for the long-term trend reports only a shared directory is required, which can be configured with the /TrendStoreDir switch. The CI pipeline by default enforces the NDepend quality gates, but if the goal is only to generate the reports, the /ForceReturnZeroExitCode switch can be used to return sucessful exit code from the CLI command.

The primary purpose of the console application seems to be providing a cross-platform way to generate reports on build machines. However, it could be also integrated with a custom VS Code build task. A developer could directly integrate it with the build process via the tasks.json file, setting up a tight development cycle, similar to one provided with the Visual Studio extension.

While currently the NDepend generates comprehensive reports, a nice addition could be incorporating the Roslyn Analyzer warnings. Fortunately, this is already in the backlog of the future features for the tool.

Feature Flags with ConfigCat and Asp.Net Core Options

&ladeak — Sun, 10 Oct 2021 09:40:25 +0000

A feature flag or 'feature toggle' is a common technique to enable or disable application features dynamically. For example, feature flags enable product owners to turn on and off features during runtime of the application. Certain features may be turned on/off for given environments, users, or regions only. This way features may be A-B tested, or tested with a given percentage of users, or different countries of the world. It can also provide a solution to meet regional restrictions of different countries.

In this post I investigate integrating ConfigCat's feature management with an ASP.NET Core 6 web API service and the Options<T> pattern. I will also focus on using the AutoPolling mechanism built into the ConfigCat client library, to refresh feature flags' state during application runtime.

Throughout my carrier I have used some sort of a feature flag solution. In some cases, this was a conscious decision built upon a well-designed application architecture, while in other cases it was just an if statement with a key-value pair in the configuration file. However, I have not yet encountered such a complete service as the one provided by ConfigCat.

I will focus on using feature flags solution within web services. Although, I see an even bigger need for such a robust solution in desktop applications. Managing the configuration of a few web service instances is inherently simpler to manage hundreds or thousands of desktop applications, which is common in the enterprise world.

Implementation Options

Feature flags can be leveraged in applications many ways. In the past, when computer networks were less ubiquitous, feature flags were typically implemented as compiler directives. This way a given code path was compiled into the application or remained as commented out section. The advantage of this solution is less branching and smaller code size. Although to 'toggle' a feature a new compilation of the source code is required, which makes this solution less dynamic. Users would need to uninstall/install or upgrade their application with the new binaries to get a feature toggled.

Today the most common technique is branching by if statements. If the features flag is in enabled state a certain code path of the application is executed. For example, when a button is clicked to start an order processing, if a given feature flag enabled an SMS is also sent to the user. One could express this as:

// ...
ProcessOrder();
var isSmsFeatureEneabled = client.GetValue("sendSMS", false);
if(isSmsFeatureEneabled)
    SendSms();
// ...

Another approach would be to leverage branching by abstractions. As this is a larger topic, I am not detailing it within this post, exploring this area may worth its own writing.

One very recent feature flag I encountered comes from .NET itself: using the HTTP3 preview feature in HttpClient requires the developers to proactively enable the feature by setting the <EnablePreviewFeatures>True</EnablePreviewFeatures> flag in the csproj file.

ConfigCat and Asp.Net Core and .NET 6

Using the ConfigCat's service does not restrict us choosing any of implementation techniques, although one would probably not choose to use compiler directives. In this section I show how one can integrate the ConfigCat's configuration with the Option<T> pattern of .NET 6. I am using a late preview version of .NET6 at the time of writing this post. DotNet 6 provides a new configuration concept with ConfigurationManager type, which is not available in the previous versions. ConfigurationManager allows to initialize configuration sources while using configuration values of previously initialized sources. It achieves this by implementing IConfigurationBuilder, IConfigurationRoot, IConfiguration interfaces at the same time.

One consideration to make is that no user specific feature flag will be used, which means that in this implementation flags will not be respected if set for specific users or 'target % users' on the ConfigCat's portal. In all cases the 'To all users' value of the feature flag is used.

In general, when using Options<T> pattern, there is no good API to query user specific settings, and in a web application used by multiple users, there is also no effective way to fetch flags for one or a few users during application startup. Thus, all feature flags shall be independent of users when being registered with Options. We can leverage though non-user specific information i.e. semantic version of the application is greater than 1.2.3. I will leave it up for the reader to extend the presented solution with such extensions.

Let me first preview the whole 'startup' code and the action of the service, then describe the necessary types I created for the solution. Here is Program.cs:

using ConfigCat.Client;
using Microsoft.Extensions.Options;

var builder = WebApplication.CreateBuilder(args);
builder.Configuration.AddConfigCat(false);
builder.Services.Configure<FeatureSet>(builder.Configuration.GetSection(nameof(FeatureSet)));
var app = builder.Build();
app.UseHttpsRedirection();
app.MapGet("api/feature", async (HttpContext context, IOptionsSnapshot<FeatureSet> features) =>
{
    if (features.Value.GrandFeature)
    {
        context.Response.StatusCode = StatusCodes.Status200OK;
        await context.Response.WriteAsync("Hello World!");
    }
    else
    {
        context.Response.StatusCode = StatusCodes.Status404NotFound;
    }
});

app.Run();

public class FeatureSet
{
    public bool GrandFeature { get; set; }
}

This web API has a single GET endpoint api/feature. The response depends on a feature flag: GrandFeature. When the feature is turned on, it returns HTTP 200 OK, with Hello World! as the content. When the feature is turned off, it returns 404 Not Found. The state of the feature flag is accessed through IOptionsSnapshot<FeatureSet> features, which I will explain later in this post.

The builder.Configuration.AddConfigCat(false); uses a custom extension method to add the toggle values of ConfigCat to the Asp.Net Core's configuration.
The second line builder.Services.Configure<FeatureSet>(builder.Configuration.GetSection(nameof(FeatureSet))); sets up the feature flags with the Options<T> pattern. This is the standard way to bind a given section of the configuration to a type, while also registering the type with the DI container. Here, I bind the configuration to a type called FeatureSet which has a single boolean property GrandFeature.

Let's investigate the custom extension method. The upcoming code focuses on getting the configuration values of ConfigCat into Asp.Net's configuration. Below the extension method uses ConfigurationManager to read the ConfigCat API key and poll interval settings from the 'appsettings.json' file. These configuration values are added by Asp.Net web application's file provider during startup. In production, one would prefer to pass the ConfigCat key as a secret or as an environment variable. In either case a configuration source would set the value before AddConfigCat is invoked. As '0' is an invalid interval for polling, the extension method validates it. The method has an optional parameter which indicates the desired behavior when ConfigCat cannot fetch the feature flags, while onError parameter is an action that is invoked in case of an exception. Feature flags are fetched from the service periodically, the onError parameter provides a way to observe errors during the background polls.

public static class Extensions
{
    public static IConfigurationBuilder AddConfigCat(
        this ConfigurationManager manager,
        bool optional = false,
        Action<Exception>? onError = null)
    {
        var key = manager["ConfigCat:Key"] ?? throw new ArgumentNullException("ConfigCat:Key");
        var pollInterval = manager.GetValue<TimeSpan>("ConfigCat:PollInterval");
        if (pollInterval == TimeSpan.Zero)
            throw new ArgumentNullException("ConfigCat:PollInterval");
        var options = new ConfigCatOptions(key, pollInterval, optional, onError);
        if (manager is IConfigurationBuilder builder)
            builder.Add(new ConfigCatConfigurationSource(options));
        return manager;
    }
}

public record ConfigCatOptions(string Key, TimeSpan RefreshInterval, bool IsOptional, Action<Exception>? OnError);

ConfigCatOptions record type is encapsulating the parameters for ConfigCatConfigurationProvider.

The next type is ConfigCatConfigurationSource. An IConfigurationSource is required to be implemented as this is the type added to the configuration sources. The responsibility of the type is to create an IConfigurationProvider. With .NET6 when a configuration provider is removed or modified, all the remaining sources are rebuilt. This implementation returns a lazily instantiated ConfigCatConfigurationProvider instance. I use the singleton semantics because auto polling built into the ConfigCatConfigurationProvider refreshes the configuration automatically.

public class ConfigCatConfigurationSource : IConfigurationSource
{
    private readonly ConfigCatOptions _options;
    private ConfigCatConfigurationProvider? _provider;

    public ConfigCatConfigurationSource(ConfigCatOptions options)
    {
        _options = options ?? throw new ArgumentNullException(nameof(options));
    }

    public IConfigurationProvider Build(IConfigurationBuilder builder) =>
        _provider ??= new ConfigCatConfigurationProvider(_options);
}

Another use case could be when the feature flags are read only at application startup. In certain applications this could be a valid scenario. For this, manual polling would be a better choice, and creating a new instance of ConfigCatConfigurationProvider on every Build() method invocation would also make sense.

The last and most complex class to implement is ConfigCatConfigurationProvider. This type derives from ConfigurationProvider which already implements many of the IConfigurationProvider interface members. Here, I only override the Load() method, which is invoked by the Host right after the configuration provider is instantiated. In the first invocation I create a new ConfigCatClient, and because AutoPollConfiguration uses a Timer to load configuration data asynchronously, a task completion source must be waited. Unfortunately, the method signature does not allow to use the await keyword. Without waiting for the task completion source, further providers would not be able to read the data set by this provider.

public class ConfigCatConfigurationProvider : ConfigurationProvider, IDisposable
{
    private readonly ConfigCatOptions _options;
    private readonly AutoPollConfiguration _polling;
    private readonly TaskCompletionSource _initialLoad;
    private IConfigCatClient? _configCatClient;

    public ConfigCatConfigurationProvider(ConfigCatOptions options)
    {
        _options = options ?? throw new ArgumentNullException(nameof(options));
        _polling = new AutoPollConfiguration
        {
            SdkKey = _options.Key ?? throw new ArgumentNullException(nameof(_options.Key)),
            PollIntervalSeconds = (uint)_options.RefreshInterval.TotalSeconds,
        };
        _initialLoad = new TaskCompletionSource();
        _polling.OnConfigurationChanged += OnConfigurationChanged;
    }

    private void OnConfigurationChanged(
        object sender,
        OnConfigurationChangedEventArgs eventArgs)
    {
        LoadData();
        _initialLoad.TrySetResult();
    }

    public void Dispose() { }

    public override void Load()
    {
        _configCatClient ??= new ConfigCatClient(_polling);
        _initialLoad.Task.GetAwaiter().GetResult();
    }

    public void LoadData()
    {
        try
        {
            Data = ParseKeys();
        }
        catch (Exception ex)
        {
            if (_options.IsOptional)
                Data = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
            if (_options.OnError is { })
                _options.OnError.Invoke(ex);
            else
                throw;
        }
        OnReload();
    }

    private IDictionary<string, string> ParseKeys()
    {
        if (_configCatClient == null)
            throw new InvalidOperationException(nameof(_configCatClient));

        var result = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
        foreach (var key in _configCatClient.GetAllKeys())
        {
            var value = _configCatClient.GetValue(key, string.Empty);
            result.Add(key.Replace('_', ':'), value);
        }
        return result;
    }
}

Once ConfigCatClient has loaded the data, the OnConfigurationChanged event is fired. This is when all key value pairs are loaded. LoadData() and ParseKeys() methods read and parse the keys and corresponding values. The result dictionary is set in the Data property, which is declared by the base class. The only additional logic applied here is to replace the underscore characters with semicolons. This is done, as the ':' character is unsupported in key names, so to deal with the hierarchy of configuration values, another character must be used for the ConfigCat feature names. Using the '_' character resembles a similar behavior to using configuration values with environment variables.

Note, that LoadData() method invokes a method from the base type: OnReload();. This will generate a new change token signaling the configuration provider that the configuration values have changed. The values of options might change due to the built-in auto-polling mechanism, however the OnConfigurationChanged event is only fired when the values have changed.

To read the latest values of configuration while serving the HTTP request, an IOptionsSnapshot<FeatureSet> is passed to the GET request's action handler. This type is useful in scenarios where options should be recomputed on every request.

Conclusion

In one way or another an aging, but still maintained application requires a solution for feature flags. The more robust this solution is the more choice is given to the development team to isolate certain preview features to certain users. Implementing a custom feature flag solution does not usually provide a competitive advantage, using service built for the purpose makes sense. In this regards, ConfigCat's solution seems a reasonable choice for my next project.