Freigeben über

.NET-Featureverwaltung

Microsoft.FeatureManagement
Microsoft.FeatureManagement.AspNetCore
Microsoft.FeatureManagement.Telemetry.ApplicationInsights

Die .NET-Featureverwaltungsbibliothek bietet eine Möglichkeit, Anwendungsfunktionen basierend auf Featurekennzeichnungen zu entwickeln und verfügbar zu machen. Wenn ein neues Feature entwickelt wird, haben viele Anwendungen spezielle Anforderungen, z. B. wann das Feature aktiviert werden soll und unter welchen Bedingungen. Diese Bibliothek bietet eine Möglichkeit, diese Beziehungen zu definieren. Es ist auch in gängige .NET-Codemuster integriert, um die Bereitstellung dieser Features zu ermöglichen.

Featurekennzeichnungen bieten eine Möglichkeit für .NET und ASP.NET Core-Anwendungen, Features dynamisch zu aktivieren oder zu deaktivieren. Sie können Featurekennzeichnungen in einfachen Anwendungsfällen wie bedingten Anweisungen verwenden. Sie können Featurekennzeichnungen auch in komplexeren Szenarien verwenden, z. B. das bedingte Hinzufügen von Routen oder MVC-Filtern (Model-View-Controller). Featurekennzeichnungen basieren auf dem .NET Core-Konfigurationssystem. Jeder .NET Core-Konfigurationsanbieter kann als Backbone für Featurekennzeichnungen fungieren.

Hier sind einige der Vorteile der Verwendung der .NET-Featureverwaltungsbibliothek:

  • Es verwendet allgemeine Konventionen für die Featureverwaltung.
  • Es hat eine niedrige Barriere für den Eintritt:
    • Es basiert auf der IConfiguration Schnittstelle.
    • Es unterstützt das Setup von Feature-Flags in JSON-Dateien.
  • Sie bietet die Verwaltung der Lebensdauer von Feature-Flags.
    • Konfigurationswerte können sich in Echtzeit ändern.
    • Featurekennzeichnungen können für die gesamte Anforderung konsistent sein.
  • Es deckt grundlegende bis komplexe Szenarien ab, indem unterstützung für die folgenden Funktionen angeboten wird:
    • Aktivieren und Deaktivieren von Features über eine deklarative Konfigurationsdatei
    • Darstellen verschiedener Varianten eines Features für unterschiedliche Benutzer
    • Dynamische Auswertung des Status eines Features basierend auf einem Aufruf an einen Server
  • Es stellt API-Erweiterungen für ASP.NET Core- und MVC-Framework in den folgenden Bereichen bereit:
    • Routing
    • Filter
    • Aktionsattribute

Die .NET-Featureverwaltungsbibliothek ist Open Source. Weitere Informationen finden Sie im FeatureManagement-Dotnet GitHub-Repository .

Featureflags

Featureflags können aktiviert oder deaktiviert werden. Der Status einer Flagge kann durch den Einsatz von Funktionsfiltern bedingt gesteuert werden.

Feature-Filter

Featurefilter definieren ein Szenario, für das ein Feature aktiviert werden soll. Um den Status eines Features auszuwerten, werden die Liste der Featurefilter durchlaufen, bis eines der Filter bestimmt, dass das Feature aktiviert ist. An diesem Punkt wird der Durchlauf durch die Featurefilter beendet. Wenn kein Featurefilter angibt, dass das Feature aktiviert werden soll, gilt es als deaktiviert.

Angenommen, Sie entwerfen einen Microsoft Edge-Browserfeaturefilter. Wenn eine HTTP-Anforderung von Microsoft Edge stammt, aktiviert Ihr Featurefilter alle Features, an die sie angefügt sind.

Featureflagkonfiguration

Das .NET Core-Konfigurationssystem wird verwendet, um den Status von Featurekennzeichnungen zu bestimmen. Die Grundlage dieses Systems ist die IConfiguration Schnittstelle. Jeder Anbieter für IConfiguration kann als Featurestatusanbieter für die Featurekennzeichnungsbibliothek verwendet werden. Dieses System unterstützt Szenarien, die von der appsettings.json Konfigurationsdatei bis hin zur Azure App-Konfiguration reichen.

Featureflagdeklaration

Die Featureverwaltungsbibliothek unterstützt die appsettings.json Konfigurationsdatei als Featurekennzeichnungsquelle, da sie ein Anbieter für das .NET Core-System IConfiguration ist. Feature-Flags werden mithilfe von Microsoft Feature Management schema deklariert. Dieses Schema ist im Ursprung sprachunabhängig und wird von allen Microsoft-Featureverwaltungsbibliotheken unterstützt.

Der Code im folgenden Beispiel deklariert Featurekennzeichen in einer JSON-Datei:

{
    "Logging": {
        "LogLevel": {
            "Default": "Warning"
        }
    },

    // Define feature flags in a JSON file.
    "feature_management": {
        "feature_flags": [
            {
                "id": "FeatureT",
                "enabled": false
            },
            {
                "id": "FeatureU",
                "enabled": true,
                "conditions": {}
            },
            {
                "id": "FeatureV",
                "enabled": true,
                "conditions": {
                    "client_filters": [
                        {  
                            "name": "Microsoft.TimeWindow",
                            "parameters": {
                                "Start": "Sun, 01 Jun 2025 13:59:59 GMT",
                                "End": "Fri, 01 Aug 2025 00:00:00 GMT"
                            }
                        }
                    ]
                }
            }
        ]
    }
}

Der feature_management Abschnitt des JSON-Dokuments wird konventionsspezifisch zum Laden von Featurekennzeichnungseinstellungen verwendet. Sie müssen Featurekennzeichnungsobjekte im feature_flags Array in diesem Abschnitt auflisten. Dieser Code listet drei Featurekennzeichnungen auf. Jedes Featurekennzeichnungsobjekt verfügt über eine id Eigenschaft und eine enabled Eigenschaft.

  • Der id Wert ist der Name, den Sie zur Identifikation und Referenzierung der Feature-Flags verwenden.
  • Die enabled-Eigenschaft gibt den aktivierten Status der Featurekennzeichnung an.

Ist enabled gleich false, dann ist eine Funktion deaktiviert. Wenn enabled den Wert true hat, hängt der Status des Features von der conditions-Eigenschaft ab. Die conditions Eigenschaft deklariert die Bedingungen, die zum dynamischen Aktivieren des Features verwendet werden.

  • Wenn ein Feature-Flag keine Eigenschaft aufweist conditions , ist das Feature aktiviert.
  • Wenn eine Featurekennzeichnung eine conditions Eigenschaft aufweist und die Bedingungen erfüllt sind, ist das Feature aktiviert.
  • Wenn eine Featurekennzeichnung eine conditions Eigenschaft aufweist und die Bedingungen nicht erfüllt sind, ist das Feature deaktiviert.

Featurefilter werden im client_filters Array definiert. Im vorherigen Code weist das FeatureV Featureflag einen Featurefilter namens Microsoft.TimeWindow auf. Dieser Filter ist ein Beispiel für einen konfigurierbaren Featurefilter. In diesem Code verfügt dieser Filter über eine parameters Eigenschaft. Diese Eigenschaft wird verwendet, um den Filter zu konfigurieren. In diesem Fall werden die Start- und Endzeiten für das zu aktive Feature konfiguriert.

Fortgeschritten: Das Doppelpunktzeichen (:) ist in Featurekennzeichnungsnamen verboten.

Anforderungstyp

Innerhalb der conditions Eigenschaft wird die requirement_type Eigenschaft verwendet, um zu bestimmen, ob die Filter beim Auswerten des Status eines Features Any oder All Logik verwenden sollen. Wenn requirement_type nicht angegeben ist, wird der Standardwert Any. Die requirement_type Werte führen zu folgendem Verhalten:

  • Any: Nur ein Filter muss als true ausgewertet werden, damit das Feature aktiviert wird.
  • All: Jeder Filter muss zu true ausgewertet werden, damit die Funktion aktiviert werden kann.

Eine requirement_type von All verändert die Art und Weise, wie die Filter durchlaufen werden:

  • Wenn keine Filter aufgelistet sind, ist das Feature deaktiviert.
  • Wenn Filter aufgelistet sind, werden sie durchlaufen, bis die Bedingungen eines Filters angeben, dass das Feature deaktiviert werden soll. Wenn kein Filter angibt, dass das Feature deaktiviert werden soll, wird es als aktiviert betrachtet.
{
    "id": "FeatureW",
    "enabled": true,
    "conditions": {
        "requirement_type": "All",
        "client_filters": [
            {
                "name": "Microsoft.TimeWindow",
                "parameters": {
                    "Start": "Sun, 01 Jun 2025 13:59:59 GMT",
                    "End": "Fri, 01 Aug 00:00:00 GMT"
                }
            },
            {
                "name": "Microsoft.Percentage",
                "parameters": {
                    "Value": "50"
                }
            }
        ]
    }
}

In diesem Beispiel hat das FeatureW Feature-Flag einen requirement_type Wert von All. Daher müssen alle seine Filter zu true ausgewertet werden, damit das Feature aktiviert werden kann. In diesem Fall ist das Feature für 50 Prozent der Benutzer im angegebenen Zeitfenster aktiviert.

Behandeln mehrerer Konfigurationsquellen

Ab v4.3.0 können Sie sich für die benutzerdefinierte Zusammenführung für Microsoft-Schemafeatureflags (Abschnitt feature_management) anmelden. Wenn dieselbe Featurekennzeichnungs-ID ConfigurationFeatureDefinitionProvider in mehreren Konfigurationsquellen angezeigt wird, führt eine Instanz der integrierten Klasse diese Definitionen gemäß der Registrierungsreihenfolge des Konfigurationsanbieters zusammen. Wenn ein Konflikt auftritt, wird die letzte Featurekennzeichnungsdefinition verwendet. Dieses Verhalten unterscheidet sich von der indexbasierten Standardzusammenführung von Arrays in .NET.

Der folgende Code ermöglicht das Zusammenführen von benutzerdefinierten Featurekennzeichnungskonfigurationen durch Abhängigkeitseinfügung:

IConfiguration configuration = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json")
    .AddJsonFile("appsettings.prod.json")
    .Build();

services.AddSingleton(configuration);
services.AddFeatureManagement();
services.Configure<ConfigurationFeatureDefinitionProviderOptions>(o =>
{
        o.CustomConfigurationMergingEnabled = true;
});

Beim Erstellen einer Instanz von ConfigurationFeatureDefinitionProvider können Sie auch das benutzerdefinierte Zusammenführen aktivieren.

var featureManager = new FeatureManager(
    new ConfigurationFeatureDefinitionProvider(
            configuration,
            new ConfigurationFeatureDefinitionProviderOptions
            {
                    CustomConfigurationMergingEnabled = true
            }));

Beispielverhalten:

// appsettings.json
{
    "feature_management": {
        "feature_flags": [
            { "id": "FeatureA", "enabled": true },
            { "id": "FeatureB", "enabled": false }
        ]
    }
}

// appsettings.prod.json (added later in ConfigurationBuilder)
{
    "feature_management": {
        "feature_flags": [
            { "id": "FeatureB", "enabled": true }
        ]
    }
}

Wenn Sie das benutzerdefinierte Zusammenführen aktivieren, bleibt FeatureA aktiviert, und FeatureB wird als aktiviert aufgelöst, weil die letzte Deklaration verwendet wird. Wenn Sie die standardmäßige .NET-Zusammenführung verwenden, bei der benutzerdefinierte Zusammenführung deaktiviert ist, werden Arrays nach Index zusammengeführt. Dieser Ansatz kann zu unerwarteten Ergebnissen führen, wenn Quellen nicht nach Position ausgerichtet werden.

.NET-Featureverwaltungsschema

In früheren Versionen der Featureverwaltungsbibliothek war das primäre Schema das .NET-Featureverwaltungsschema.

Ab Version 4.0.0 der Bibliothek werden neue Features, einschließlich Varianten und Telemetrie, nicht im .NET-Featureverwaltungsschema unterstützt.

Hinweis

Wenn die Featurekennzeichnungskonfiguration eine Deklaration enthält, die sowohl in den feature_management- als auch in den FeatureManagement-Abschnitten aufgeführt ist, wird die Deklaration aus dem feature_management-Abschnitt übernommen.

Nutzung

In einer einfachen Implementierung überprüft die Featureverwaltung, ob ein Feature-Flag aktiviert ist. Anschließend führt sie Aktionen basierend auf dem Ergebnis aus. Diese Überprüfung erfolgt über die IsEnabledAsync Methode von IVariantFeatureManager.

…
IVariantFeatureManager featureManager;
…
if (await featureManager.IsEnabledAsync("FeatureX"))
{
    // Do something.
}

Dienstregistrierung

Die Featureverwaltung basiert auf .NET Core-Abhängigkeitsinjektion. Wie der folgende Code zeigt, können Sie Standardkonventionen verwenden, um Featureverwaltungsdienste zu registrieren:

using Microsoft.FeatureManagement;

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddFeatureManagement();
    }
}

Standardmäßig ruft der Feature-Manager die Featurekennzeichnungskonfiguration aus dem feature_management Oder FeatureManagement Abschnitt der .NET Core-Konfigurationsdaten ab. Wenn keines der Abschnitte vorhanden ist, wird die Konfiguration als leer betrachtet.

Hinweis

Sie können auch angeben, dass die Featurekennzeichnungskonfiguration aus einem anderen Konfigurationsabschnitt abgerufen werden soll, indem Sie den Abschnitt AddFeatureManagementan übergeben. Im folgenden Beispiel wird angegeben, dass der Feature-Manager stattdessen aus einem Abschnitt namens MyFeatureFlags lesen soll:

services.AddFeatureManagement(configuration.GetSection("MyFeatureFlags"));

Abhängigkeitsinjektion

Wenn Sie die Featureverwaltungsbibliothek mit MVC verwenden, können Sie das Objekt abrufen, das mithilfe der Abhängigkeitseinfügung IVariantFeatureManager implementiert wird.

public class HomeController : Controller
{
    private readonly IVariantFeatureManager _featureManager;
    
    public HomeController(IVariantFeatureManager featureManager)
    {
        _featureManager = featureManager;
    }
}

Bereichsbezogene Featureverwaltungsdienste

Die AddFeatureManagement Methode fügt Featureverwaltungsdienste als Singletons innerhalb einer Anwendung hinzu. In einigen Szenarien müssen stattdessen Featureverwaltungsdienste als bereichsbezogene Dienste hinzugefügt werden. Sie können beispielsweise Featurefilter verwenden, die bereichsbezogene Dienste für Kontextinformationen nutzen. In diesem Fall sollten Sie die AddScopedFeatureManagement Methode verwenden. Durch diese Methode wird sichergestellt, dass Featureverwaltungsdienste, einschließlich Featurefiltern, als bereichsbezogene Dienste hinzugefügt werden.

services.AddScopedFeatureManagement();

ASP.NET Core-Integration

Die Featureverwaltungsbibliothek bietet Funktionen in ASP.NET Core und MVC, um allgemeine Featurekennzeichnungsszenarien in Webanwendungen zu ermöglichen. Diese Funktionen sind verfügbar, indem sie auf das Microsoft.FeatureManagement.AspNetCore-NuGet-Paket verweisen.

Controller und Aktionen

Ein MVC-Controller und -Aktionen können erfordern, dass ein bestimmtes Feature oder eine beliebige Liste von Features aktiviert werden kann, um ausgeführt werden zu können. Sie können diese Anforderung mithilfe eines FeatureGateAttribute Objekts erfüllen. Die FeatureGateAttribute Klasse wird im Microsoft.FeatureManagement.Mvc Namespace definiert.

[FeatureGate("FeatureX")]
public class HomeController : Controller
{
    …
}

Im vorangehenden Beispiel wird die HomeController Klasse von FeatureX gesteuert. HomeController Aktionen können nur ausgeführt werden, wenn das FeatureX Feature aktiviert ist.

[FeatureGate("FeatureX")]
public IActionResult Index()
{
    return View();
}

Im vorherigen Beispiel kann die Index MVC-Aktion nur ausgeführt werden, wenn das FeatureX Feature aktiviert ist.

Deaktivierte Aktionsbehandlung

Wenn ein MVC-Controller oder eine Aktion blockiert wird, weil keine der von ihr definierten Features aktiviert ist, wird eine registrierte Implementierung IDisabledFeaturesHandler aufgerufen. Standardmäßig wird ein minimalistischer Handler registriert, der einen HTTP 404-Fehler zurückgibt. Sie können diesen Handler überschreiben, indem Sie IFeatureManagementBuilder verwenden, wenn Sie Feature-Flags registrieren.

public interface IDisabledFeaturesHandler
{
    Task HandleDisabledFeatures(IEnumerable<string> features, ActionExecutingContext context);
}

Sicht

In MVC-Ansichten können Sie Tags verwenden <feature> , um Inhalte bedingt zu rendern. Sie können die Renderingbedingungen darauf basieren, ob ein Feature aktiviert ist oder ob eine bestimmte Variante eines Features zugewiesen ist. Weitere Informationen finden Sie unter Variants weiter unten in diesem Artikel.

<feature name="FeatureX">
  <p>This content appears only when 'FeatureX' is enabled.</p>
</feature>

<feature name="FeatureX" variant="Alpha">
  <p>This content appears only when variant 'Alpha' of 'FeatureX' is assigned.</p>
</feature>

Sie können die Markierungshilfsauswertung auch negieren, wenn Sie Inhalte anzeigen möchten, wenn ein Feature oder eine Gruppe von Features deaktiviert ist. Wenn Sie negate="true" wie in den folgenden Beispielen angeben, wird der Inhalt nur gerendert, wenn FeatureX deaktiviert ist.

<feature negate="true" name="FeatureX">
  <p>This content appears only when 'FeatureX' is disabled.</p>
</feature>

<feature negate="true" name="FeatureX" variant="Alpha">
  <p>This content appears only when variant 'Alpha' of 'FeatureX' isn't assigned.</p>
</feature>

Sie können das <feature> Tag verwenden, um auf mehrere Features zu verweisen. Geben Sie dazu eine durch Trennzeichen getrennte Liste der Features im name Attribut an.

<feature name="FeatureX,FeatureY">
  <p>This content appears only when 'FeatureX' and 'FeatureY' are enabled.</p>
</feature>

Standardmäßig müssen alle aufgelisteten Features aktiviert sein, damit die Featurekennzeichnung gerendert wird. Sie können dieses Verhalten überschreiben, indem Sie das requirement Attribut hinzufügen, wie im folgenden Beispiel gezeigt.

<feature name="FeatureX,FeatureY" requirement="Any">
  <p>This content appears only when 'FeatureX,' 'FeatureY,' or both are enabled.</p>
</feature>

Sie können das <feature> Tag auch verwenden, um auf mehrere Varianten zu verweisen. Verwenden Sie dazu einen Wert von requirement und Any, und geben Sie eine kommagetrennte Liste von Varianten im variant-Attribut an.

<feature name="FeatureX" variant="Alpha,Beta" requirement="Any">
  <p>This content appears only when variant 'Alpha' or 'Beta' of 'FeatureX' is assigned.</p>
</feature>

Hinweis

  • Wenn Sie eine Variante angeben, sollten Sie nur ein Feature angeben.
  • Wenn Sie mehrere Varianten angeben und einen requirement Wert von And verwenden, wird ein Fehler erzeugt. Sie können nicht mehrere Varianten zuweisen.

Die <feature>-Kennzeichnung erfordert ein Kennzeichnungshilfsprogramm. Um das Tag zu verwenden, fügen Sie der Datei _ViewImports.cshtml das Tag-Hilfsprogramm für das Feature-Management hinzu.

@addTagHelper *, Microsoft.FeatureManagement.AspNetCore

MVC-Filter

Sie können MVC-Aktionsfilter einrichten, die Sie basierend auf dem Status eines Features bedingt anwenden. Um diese Filter einzurichten, registrieren Sie sie auf eine feature-sensible Weise. Die Featureverwaltungspipeline unterstützt asynchrone MVC-Aktionsfilter, die die IAsyncActionFilter Schnittstelle implementieren.

services.AddMvc(o => 
{
    o.Filters.AddForFeature<SomeMvcFilter>("FeatureX");
});

Der vorangehende Code registriert einen MVC-Filter mit dem Namen SomeMvcFilter. Dieser Filter wird nur innerhalb der MVC-Pipeline ausgelöst, wenn FeatureX er aktiviert ist.

Razor-Seiten

MVC Razor-Seiten können erfordern, dass ein bestimmtes Feature oder eine beliebige Liste von Features aktiviert werden kann, um ausgeführt werden zu können. Sie können diese Anforderung mithilfe eines FeatureGateAttribute Objekts hinzufügen. Die FeatureGateAttribute Klasse wird im Microsoft.FeatureManagement.Mvc Namespace definiert.

[FeatureGate("FeatureX")]
public class IndexModel : PageModel
{
    public void OnGet()
    {
    }
}

Der vorangehende Code richtet eine Razor-Seite ein, für die die FeatureX Aktivierung erforderlich ist. Wenn das Feature nicht aktiviert ist, generiert die Seite ein HTTP 404 (NotFound)-Ergebnis.

Wenn Sie ein FeatureGateAttribute-Objekt auf Razor Pages verwenden, müssen Sie FeatureGateAttribute auf den Seitenhandlertyp platzieren. Sie können es nicht auf einzelne Handlermethoden anwenden.

Anwendungserstellung

Sie können die Featureverwaltungsbibliothek verwenden, um Anwendungszweige und Middleware hinzuzufügen, die bedingt basierend auf dem Status eines Features ausgeführt werden.

app.UseMiddlewareForFeature<ThirdPartyMiddleware>("FeatureX");

Im vorherigen Code fügt die Anwendung eine Middleware-Komponente hinzu, die nur dann in der Anforderungspipeline angezeigt wird, wenn das FeatureX Feature aktiviert ist. Wenn das Feature während der Laufzeit aktiviert oder deaktiviert ist, kann die Middlewarepipeline dynamisch geändert werden.

Wie der folgende Code zeigt, nutzt diese Funktionalität die allgemeine Möglichkeit, die gesamte Anwendung basierend auf einem Feature zu verzweigen.

app.UseForFeature(featureName, appBuilder => 
{
    appBuilder.UseMiddleware<T>();
});

Implementieren eines Featurefilters

Das Erstellen eines Featurefilters bietet eine Möglichkeit, Features basierend auf von Ihnen definierten Kriterien zu aktivieren. Um einen Featurefilter zu implementieren, müssen Sie die IFeatureFilter Schnittstelle implementieren. IFeatureFilter hat eine einzelne Methode mit dem Namen EvaluateAsync. Wenn ein Feature angibt, dass es für einen Featurefilter aktiviert werden kann, wird die EvaluateAsync-Methode aufgerufen. Wenn EvaluateAsynctrue ausgibt, sollte das Feature aktiviert werden.

Der folgende Code veranschaulicht das Hinzufügen eines benutzerdefinierten Featurefilters mit dem Namen .The following code demonstrates how to add a custom feature filter called MyCriteriaFilter.

services.AddFeatureManagement()
        .AddFeatureFilter<MyCriteriaFilter>();

Sie können einen Featurefilter registrieren, indem Sie AddFeatureFilter<T> für die von AddFeatureManagement zurückgegebene IFeatureManagementBuilder-Implementierung aufrufen. Der Featurefilter hat Zugriff auf die Dienste in der Dienstsammlung, die Sie zum Hinzufügen von Featurekennzeichnungen verwenden. Die Abhängigkeitseinfügung kann zum Abrufen dieser Dienste verwendet werden.

Hinweis

Wenn Sie in Featurekennzeichnungseinstellungen auf Filter verweisen (z. B. appsettings.json), sollten Sie den Filter Teil des Typnamens weglassen. Weitere Informationen finden Sie unter Filter-Alias-Attribut, weiter unten in diesem Artikel.

Parametrisierte Merkmalfilter

Einige Featurefilter erfordern Parameter, um auszuwerten, ob ein Feature aktiviert werden soll. Beispielsweise kann ein Browserfeaturefilter ein Feature für eine bestimmte Gruppe von Browsern aktivieren. Möglicherweise möchten Sie ein Feature in den Browsern Microsoft Edge und Chrome aktivieren, aber nicht in Firefox.

Um diese Filterung zu implementieren, können Sie einen Featurefilter entwerfen, um Parameter zu erwarten. Sie geben diese Parameter in der Featurekonfiguration an. Im Code greifen Sie auf den FeatureFilterEvaluationContext-Parameter von IFeatureFilter.EvaluateAsync darauf zu.

public class FeatureFilterEvaluationContext
{
    /// <summary>
    /// The name of the feature being evaluated
    /// </summary>
    public string FeatureName { get; set; }

    /// <summary>
    /// The settings provided for the feature filter to use when evaluating whether the feature should be enabled
    /// </summary>
    public IConfiguration Parameters { get; set; }
}

Die FeatureFilterEvaluationContext Klasse hat eine Eigenschaft mit dem Namen Parameters. Die Parameter dieser Eigenschaft stellen eine unformatierte Konfiguration dar, die der Featurefilter verwenden kann, wenn ausgewertet wird, ob das Feature aktiviert werden soll. Im Browserfeaturefilterbeispiel kann der Filter die Parameters Eigenschaft verwenden, um einen Satz zulässiger Browser zu extrahieren, die für das Feature angegeben sind. Der Filter kann dann überprüfen, ob die Anforderung von einem dieser Browser stammt.

[FilterAlias("Browser")]
public class BrowserFilter : IFeatureFilter
{
    …

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

        //
        // Use the settings to check whether the request is from a browser in BrowserFilterSettings.AllowedBrowsers.
    }
}

Filteraliasattribut

Wenn Sie einen Feature-Filter für eine Feature-Flag registrieren, ist der Alias, den Sie in der Konfiguration verwenden, der Name des Feature-Filter-Typs, wobei das Filter Suffix (falls vorhanden) entfernt wird. Sie sollten zum Beispiel in der Konfiguration auf MyCriteriaFilter als MyCriteria verweisen.

{
    "id": "MyFeature",
    "enabled": true,
    "conditions": {
        "client_filters": [
            {
                "name": "MyCriteria"
            }
        ]
    }
}

Sie können diesen Namen überschreiben, indem Sie die FilterAliasAttribute Klasse verwenden. Um einen Namen zu deklarieren, der in der Konfiguration verwendet werden soll, um auf einen Featurefilter in einem Featurekennzeichen zu verweisen, können Sie den Featurefilter mit diesem Attribut versehen.

Fehlende Filter für Funktionen

Angenommen, Sie konfigurieren ein Feature, das für einen bestimmten Featurefilter aktiviert werden soll. Wenn dieser Featurefilter nicht registriert ist, wird eine Ausnahme ausgelöst, wenn das Feature ausgewertet wird. Wie der folgende Code zeigt, können Sie die Ausnahme mithilfe von Featureverwaltungsoptionen deaktivieren.

services.Configure<FeatureManagementOptions>(options =>
{
    options.IgnoreMissingFeatureFilters = true;
});

Verwenden von HttpContext

Featurefilter können auswerten, ob ein Feature basierend auf den Eigenschaften einer HTTP-Anforderung aktiviert werden soll. Diese Überprüfung wird durchgeführt, indem der HTTP-Kontext überprüft wird. Wie der folgende Code zeigt, kann ein Featurefilter mithilfe der Abhängigkeitsinjektion eine Implementierung von IHttpContextAccessor abrufen, um einen Verweis auf den HTTP-Kontext zu erhalten.

public class BrowserFilter : IFeatureFilter
{
    private readonly IHttpContextAccessor _httpContextAccessor;

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

Sie müssen die IHttpContextAccessor Implementierung zum Container zum Einfügen von Abhängigkeiten beim Start hinzufügen, damit sie verfügbar ist. Sie können die folgende Methode verwenden, um die Implementierung in den IServiceCollection Diensten zu registrieren.

public void ConfigureServices(IServiceCollection services)
{
    …
    services.AddHttpContextAccessor();
    …
}

Fortgeschritten:IHttpContextAccessor und HttpContext sollten nicht in den Razor-Komponenten von serverseitigen Blazor-Apps verwendet werden. Der empfohlene Ansatz zum Übergeben des HTTP-Kontexts in Blazor-Apps besteht darin, die Daten in einen bereichsbezogenen Dienst zu kopieren. Für Blazor-Apps sollten Sie AddScopedFeatureManagement verwenden, um Feature-Management-Dienste zu registrieren. Weitere Informationen finden Sie unter Bereichsbezogene Featureverwaltungsdienste weiter oben in diesem Artikel.

Bereitstellen eines Kontexts für die Featureauswertung

In Konsolenanwendungen gibt es keinen Umgebungskontext wie HttpContext, den Featurefilter nutzen können, um festzustellen, ob ein Feature aktiviert werden soll. In diesem Fall müssen Anwendungen ein Objekt bereitstellen, das einen Kontext zum Featureverwaltungssystem für die Verwendung durch Featurefilter darstellt. Sie können IVariantFeatureManager.IsEnabledAsync<TContext>(string featureName, TContext appContext) verwenden, um diesen Kontext bereitzustellen. Um den Status eines Features auszuwerten, können Featurefilter das appContext Objekt verwenden, das Sie dem Feature-Manager bereitstellen.

MyAppContext context = new MyAppContext
{
    AccountId = current.Id
};

if (await featureManager.IsEnabledAsync(feature, context))
{
…
}

Kontextbezogene Merkmalfilter

Kontextbezogene Featurefilter implementieren die IContextualFeatureFilter<TContext>-Schnittstelle. Diese speziellen Featurefilter können den Kontext nutzen, der übergeben wird, wenn IVariantFeatureManager.IsEnabledAsync<TContext> aufgerufen wird. Der TContext Typparameter in IContextualFeatureFilter<TContext> beschreibt den Kontexttyp, den der Filter verarbeiten kann. Wenn Sie einen Kontextfeaturefilter entwickeln, können Sie die Anforderungen für die Verwendung des Filters festlegen, indem Sie einen Kontexttyp angeben.

Da jeder Typ ein abgeleiteter Typ der Object-Klasse ist, kann ein implementierter Filter in jedem bereitgestellten IContextualFeatureFilter<object>-Kontext aufgerufen werden. Der folgende Code enthält ein Beispiel für einen bestimmten Kontextmerkmal-Filter. In diesem Code wird ein Feature aktiviert, wenn sich ein Konto in einer konfigurierten Liste der aktivierten Konten befindet.

public interface IAccountContext
{
    string AccountId { get; set; }
}

[FilterAlias("AccountId")]
class AccountIdFilter : IContextualFeatureFilter<IAccountContext>
{
    public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext featureEvaluationContext, IAccountContext accountId)
    {
        //
        // Evaluate whether the feature should be on by using the IAccountContext that's provided.
    }
}

Die AccountIdFilter Klasse erfordert, dass ein Objekt bereitgestellt wird, das IAccountContext implementiert, um den Status einer Funktion auswerten zu können. Wenn Sie diesen Funktionsfilter verwenden, muss der Aufrufer sicherstellen, dass das übergebene Objekt IAccountContext implementiert.

Hinweis

Nur eine einzelne Featurefilterschnittstelle kann von einem einzelnen Typ implementiert werden. Wenn Sie versuchen, einen Featurefilter hinzuzufügen, der mehr als eine einzelne Featurefilterschnittstelle implementiert, führt dies zu einer ArgumentException Ausnahme.

Verwenden von kontextbezogenen und nicht kontextbezogenen Filtern mit demselben Alias

Filter, die IFeatureFilter und IContextualFeatureFilter implementieren, können denselben Alias gemeinsam nutzen. Insbesondere können Sie einen Filteralias verwenden, der von null oder einer IFeatureFilter-Implementierung und null oder NIContextualFeatureFilter<ContextType> Implementierungen gemeinsam verwendet wird, wenn es höchstens einen anwendbaren Filter für ContextType gibt.

Um den Prozess der Auswahl eines Filters zu verstehen, wenn kontextbezogene und nicht kontextbezogene Filter mit demselben Namen in einer Anwendung registriert sind, betrachten Sie das folgende Beispiel.

Drei Filter teilen den SharedFilterName Alias:

  • Ein nicht kontextbezogener Filter namens FilterA
  • Ein kontextbezogener Filter, FilterB der einen TypeB Kontext akzeptiert
  • Ein kontextbezogener Filter, FilterC der einen TypeC Kontext akzeptiert

Ein Feature-Flag namens MyFeature verwendet den Featurefilter SharedFilterName in seiner Konfiguration.

Wenn alle drei Filter registriert sind:

  • Beim Aufrufen von IsEnabledAsync("MyFeature") wird der FilterA-Filter verwendet, um den Feature-Flag auszuwerten.
  • Wenn Sie anrufen IsEnabledAsync("MyFeature", context):
    • Wenn der Typ von context ist TypeB, FilterB wird verwendet.
    • Wenn der Typ von context ist TypeC, FilterC wird verwendet.
    • Wenn der Typ von context ist TypeF, FilterA wird verwendet.

Integrierte Funktionsfilter

Es gibt einige Featurefilter, die im Microsoft.FeatureManagement Paket enthalten sind: PercentageFilter, , TimeWindowFilter, ContextualTargetingFilterund TargetingFilter. Alle Filter außer TargetingFilter werden automatisch hinzugefügt, wenn Sie die AddFeatureManagement Methode verwenden, um die Featureverwaltung zu registrieren. TargetingFilter wird mithilfe der WithTargeting Methode hinzugefügt. Weitere Informationen finden Sie unter "Targeting" weiter unten in diesem Artikel.

Jeder der integrierten Featurefilter verfügt über eigene Parameter. In den folgenden Abschnitten werden diese Featurefilter beschrieben und Beispiele bereitgestellt.

Microsoft.Percentage

Der Microsoft.Percentage Filter bietet eine Möglichkeit, ein Feature basierend auf einem festgelegten Prozentsatz zu aktivieren.

{
    "id": "EnhancedPipeline",
    "enabled": true,
    "conditions": {
        "client_filters": [
            {
                "name": "Microsoft.Percentage",
                "parameters": {
                    "Value": 50
                }
            }
        ]
    }
}

Microsoft.TimeWindow

Der Microsoft.TimeWindow Filter bietet eine Möglichkeit, ein Feature basierend auf einem Zeitfenster zu aktivieren.

  • Wenn Sie nur einen End Wert angeben, wird das Feature bis zu diesem Zeitpunkt als aktiviert betrachtet.
  • Wenn nur ein Start-Wert angegeben wird, wird das Feature zu allen Zeitpunkten als aktiviert berücksichtigt.
{
    "id": "EnhancedPipeline",
    "enabled": true,
    "conditions": {
        "client_filters": [
            {
                "name": "Microsoft.TimeWindow",
                "parameters": {
                    "Start": "Sun, 01 Jun 2025 13:59:59 GMT",
                    "End": "Fri, 01 Aug 2025 00:00:00 GMT"
                }
            }
        ]
    }
}

Sie können den Filter so konfigurieren, dass ein Zeitfenster auf wiederkehrender Basis angewendet wird. Diese Funktion kann nützlich sein, wenn Sie ein Feature während eines Zeitraums mit geringem oder hohem Datenverkehr an einem Tag oder an bestimmten Tagen der Woche aktivieren müssen. Um ein einzelnes Zeitfenster auf ein Wiederkehrendes Zeitfenster zu erweitern, verwenden Sie einen Recurrence Parameter, um eine Serienregel anzugeben.

Hinweis

Um Wiederholungen zu verwenden, müssen Sie Start- und End-Werte angeben. Bei Wiederholungen gibt der Datumsteil des End Werts kein Enddatum an, um den filter aktiv zu berücksichtigen. Stattdessen verwendet der Filter das Enddatum relativ zum Startdatum, um die Dauer des Zeitfensters zu definieren, das rekursiert wird.

{
    "id": "EnhancedPipeline",
    "enabled": true,
    "conditions": {
        "client_filters": [
            {
                "name": "Microsoft.TimeWindow",
                "parameters": {
                    "Start": "Fri, 22 Mar 2024 20:00:00 GMT",
                    "End": "Sat, 23 Mar 2024 02:00:00 GMT",
                    "Recurrence": {
                        "Pattern": {
                            "Type": "Daily",
                            "Interval": 1
                        },
                        "Range": {
                            "Type": "NoEnd"
                        }
                    }
                }
            }
        ]
    }
}

Die Recurrence Einstellungen bestehen aus zwei Teilen:

  • Die Pattern Einstellungen geben an, wie oft das Zeitfenster wiederholt wird.
  • Die Range Einstellungen geben an, wie lange das Serienmuster wiederholt wird.

Serienmuster

Es gibt zwei mögliche Serienmustertypen: Daily und Weekly. Beispielsweise kann ein Zeitfenster jeden Tag, alle drei Tage, jeden Montag oder jeden anderen Freitag wiederholt werden.

Je nach Typ sind bestimmte Felder der Pattern Einstellungen erforderlich, optional oder ignoriert.

  • Daily

    Das tägliche Wiederholungsmuster verursacht, dass das Zeitfenster gemäß einer festgelegten Anzahl von Tagen zwischen den einzelnen Vorkommen wiederholt wird.

    Eigenschaft Relevance BESCHREIBUNG
    Type Erforderlich Der Wiederholungsmustertyp. Muss auf Daily festgelegt sein.
    Interval Optional Die Anzahl der Tage zwischen jedem Vorkommen. Der Standardwert ist 1.

  • Weekly

    Das wöchentliche Serienmuster bewirkt, dass das Zeitfenster am selben Tag oder an tagen der Woche wiederholt wird. Sie können jedoch die Anzahl der Wochen zwischen den einzelnen Vorkommen angeben.

    Eigenschaft Relevance BESCHREIBUNG
    Type Erforderlich Der Serienmustertyp. Muss auf Weekly festgelegt sein.
    DaysOfWeek Erforderlich Die Wochentage, an der das Ereignis stattfindet.
    Interval Optional Die Anzahl der Wochen zwischen den einzelnen Vorkommen. Der Standardwert ist 1.
    FirstDayOfWeek Optional Der Tag, der als erster Tag der Woche verwendet werden soll. Der Standardwert ist Sunday.

    Dieses Beispiel wiederholt das Zeitfenster jeden zweiten Montag und Dienstag:

    "Pattern": {
    "Type": "Weekly",
    "Interval": 2,
    "DaysOfWeek": ["Monday", "Tuesday"]
}

Hinweis

Der Start Wert muss ein gültiges erstes Vorkommen sein, das zum Serienmuster passt. Außerdem kann die Dauer des Zeitfensters nicht länger sein als die Anzahl der Vorkommen. Beispielsweise kann ein 25-Stunden-Zeitfenster nicht täglich auftreten.

Serienbereich

Es gibt drei mögliche Serienbereichstypen: NoEnd, EndDate und Numbered.

  • NoEnd

    Der NoEnd-Bereich bewirkt, dass die Serie unbegrenzt auftritt.

    Eigenschaft Relevance BESCHREIBUNG
    Type Erforderlich Der Serienbereichstyp. Muss auf NoEnd festgelegt sein.

  • EndDate

    Der EndDate-Bereich bewirkt, dass das Zeitfenster an allen Tagen auftritt, die dem entsprechenden Muster bis zum Enddatum entsprechen.

    Eigenschaft Relevance BESCHREIBUNG
    Type Erforderlich Der Serienbereichstyp. Muss auf EndDate festgelegt sein.
    EndDate Erforderlich Das Datum und die Uhrzeit, an dem das Anwenden des Musters beendet werden soll. Wenn die Startzeit des letzten Vorkommens vor dem Enddatum liegt, kann sich die Endzeit dieses Vorkommens darüber hinaus erstrecken.

    Im folgenden Beispiel wird das Zeitfenster jeden Tag bis zum letzten Vorkommen am 1. April 2024 wiederholt.

    "Start": "Fri, 22 Mar 2024 18:00:00 GMT",
"End": "Fri, 22 Mar 2024 20:00:00 GMT",
"Recurrence":{
    "Pattern": {
        "Type": "Daily",
        "Interval": 1
    },
    "Range": {
        "Type": "EndDate",
        "EndDate": "Mon, 1 Apr 2024 20:00:00 GMT"
    }
}

  • Numbered

    Der Numbered Bereich bewirkt, dass das Zeitfenster eine bestimmte Anzahl von Malen auftritt.

    Eigenschaft Relevance BESCHREIBUNG
    Type Erforderlich Der Serienbereichstyp. Muss auf Numbered festgelegt sein.
    NumberOfOccurrences Erforderlich Die Anzahl der Vorkommen.

    Im folgenden Beispiel wiederholt sich das Zeitfenster montags und dienstags für insgesamt drei Vorkommen, die an den folgenden Datumsangaben auftreten:

    • Montag, 1. April
    • Dienstag, 2. April
    • Montag, 8. April
    "Start": "Mon, 1 Apr 2024 18:00:00 GMT",
"End": "Mon, 1 Apr 2024 20:00:00 GMT",
"Recurrence":{
    "Pattern": {
        "Type": "Weekly",
        "Interval": 1,
        "DaysOfWeek": ["Monday", "Tuesday"]
    },
    "Range": {
        "Type": "Numbered",
        "NumberOfOccurrences": 3
    }
}

Um eine Serienregel zu erstellen, müssen Sie sowohl Pattern- als auch Range-Einstellungen angeben. Jeder Mustertyp kann mit jedem Bereichstyp verwendet werden.

Erweitert: Der Zeitzonenoffset der Start-Eigenschaft wird auf die Serieneinstellungen angewendet.

Microsoft.Targeting

Der Microsoft.Targeting Filter bietet eine Möglichkeit, ein Feature für eine Zielgruppe zu aktivieren. Eine ausführliche Erläuterung der Zielbestimmung finden Sie weiter unten in diesem Artikel unter "Targeting".

Die Filterparameter enthalten ein Audience Objekt, das beschreibt, wer Zugriff auf das Feature hat. Innerhalb des Audience Objekts können Sie Benutzer, Gruppen, ausgeschlossene Benutzer und Gruppen und einen Standardprozentsatz der Benutzerbasis angeben.

Für jedes Gruppenobjekt, das Sie im Groups Abschnitt auflisten, müssen Sie auch angeben, welcher Prozentsatz der Mitglieder der Gruppe Zugriff haben soll.

Für jeden Benutzer wird das Feature wie folgt ausgewertet:

  • Wenn der Benutzer ausgeschlossen ist, ist das Feature für den Benutzer deaktiviert. Sie können den Benutzer ausschließen, indem Sie:

    • Auflisten des Namens unter Users im Exclusion-Abschnitt.
    • Auflisten einer Gruppe, zu der ein Benutzer gehört, unter Groups im Abschnitt Exclusion.

  • Wenn der Benutzer nicht ausgeschlossen ist, wird das Feature aktiviert, wenn eine der folgenden Bedingungen erfüllt ist:

    • Der Benutzer wird im Users Abschnitt aufgeführt.
    • Der Benutzer befindet sich in dem Prozentsatz, der in einem der Gruppen-Rollouts enthalten ist.
    • Der Benutzer fällt in den Standard-Rollout-Prozentsatz.

  • Wenn keines der vorherigen Fälle zutrifft, ist das Feature für den Benutzer deaktiviert. Wenn der Benutzer z. B. nicht in der eingeschlossenen prozentualen Gruppe ist, ist die Funktion deaktiviert.

{
    "id": "EnhancedPipeline",
    "enabled": true,
    "conditions": {
        "client_filters": [
            {
                "name": "Microsoft.Targeting",
                "parameters": {
                    "Audience": {
                        "Users": [
                            "Jeff",
                            "Alicia"
                        ],
                        "Groups": [
                            {
                                "Name": "Ring0",
                                "RolloutPercentage": 100
                            },
                            {
                                "Name": "Ring1",
                                "RolloutPercentage": 50
                            }
                        ],
                        "DefaultRolloutPercentage": 20,
                        "Exclusion": {
                            "Users": [
                                "Ross"
                            ],
                            "Groups": [
                                "Ring2"
                            ]
                        }
                    }
                }
            }
        ]
    }
}

Aliasnamespaces für Featurefilter

Alle integrierten Featurefilteraliasen befinden sich im Microsoft Featurefilternamespace. Wenn Sie sich in diesem Namespace befinden, werden Konflikte mit anderen Featurefiltern verhindert, die denselben Alias verwenden. Die Segmente eines Featurefilternamespaces werden durch das . Zeichen geteilt. Sie können auf einen Featurefilter anhand seines vollständigen Namens verweisen, z. B. Microsoft.Percentage. Sie können auch auf das letzte Segment verweisen, wie zum Beispiel Percentage.

Ziel

Die Zielbestimmung ist eine Featureverwaltungsstrategie, mit der Sie neue Features schrittweise für Ihre Benutzerbasis bereitstellen können. Die Strategie basiert auf dem Konzept der Zielgruppenadressierung einer Gruppe von Benutzern, die als Zielgruppe bezeichnet werden. Eine Benutzergruppe besteht aus bestimmten Benutzern, Gruppen, ausgeschlossenen Benutzern und Gruppen und einem bestimmten Prozentsatz der gesamten Benutzerbasis. Die Gruppen, die in der Zielgruppe enthalten sind, können weiter in Prozentsätze ihrer Gesamtmitglieder unterteilt werden.

Die folgenden Schritte veranschaulichen ein Beispiel für ein progressives Rollout für ein neues Feature namens Beta:

  1. Einzelnen Benutzern jeff und Alicia werden Zugriff auf das Beta-Feature gewährt.
  2. Ein anderer Benutzer, Mark, fordert die Anmeldung an und wird aufgenommen.
  3. Zwanzig Prozent der Benutzer in der Gruppe "Ring1" sind im Beta-Feature enthalten.
  4. Die Anzahl der eingeschlossenen Ring1-Benutzer wird auf 100 Prozent erhöht.
  5. Fünf Prozent der Benutzerbasis sind im Beta-Feature enthalten.
  6. Der Rollout-Prozentsatz wird auf 100 Prozent erhöht, um das Feature vollständig einzuführen.

Die Bibliothek unterstützt diese Strategie für das Rollout eines Features über den integrierten Microsoft.Targeting-Featurefilter .

Zielbestimmung in einer Webanwendung

Ein Beispiel für eine Webanwendung, die den Zielfeaturefilter verwendet, finden Sie im Beispielprojekt FeatureFlagDemo .

Um mit der Verwendung TargetingFilter in einer Anwendung zu beginnen, müssen Sie sie wie jeder andere Featurefilter der Dienstsammlung der Anwendung hinzufügen. Im Gegensatz zu anderen eingebauten Filtern beruht er auf einem anderen Dienst, TargetingFilter, der zur Dienstsammlung der Anwendung hinzugefügt werden muss. Dieser Dienst ist eine ITargetingContextAccessor Implementierung.

Die Microsoft.FeatureManagement.AspNetCore Bibliothek bietet eine Standardimplementierung, die Zielinformationen aus dem Wert einer ITargetingContextAccessor Anforderung HttpContext extrahiert. Sie können den standardmäßigen Zielkontext-Accessor verwenden, wenn Sie das Targeting einrichten, indem Sie die nicht generische Überladung WithTargeting für IFeatureManagementBuilder verwenden.

Um den standardmäßigen Zielkontext-Accessor und TargetingFilter zu registrieren, rufen Sie WithTargeting für IFeatureManagementBuilder auf.

services.AddFeatureManagement()
        .WithTargeting();

Sie können auch eine benutzerdefinierte Implementierung für ITargetingContextAccessor und TargetingFilter durch Aufrufen von WithTargeting<T> registrieren. Der folgende Code richtet die Featureverwaltung in einer Webanwendung ein, um TargetingFilter mit einer Implementierung von ITargetingContextAccessor, die ExampleTargetingContextAccessor genannt wird, zu verwenden.

services.AddFeatureManagement()
        .WithTargeting<ExampleTargetingContextAccessor>();

ITargetingContextAccessor

Für die Verwendung von TargetingFilter in einer Webanwendung ist eine Implementierung von ITargetingContextAccessor erforderlich. Der Grund für diese Anforderung besteht darin, dass kontextbezogene Informationen, z. B. Informationen über den Benutzer, für die Zielgruppenauswertung benötigt werden. Diese Informationen werden in Instanzen der TargetingContext Klasse gespeichert. Verschiedene Anwendungen extrahieren diese Informationen an verschiedenen Stellen, z. B. den HTTP-Kontext einer Anforderung oder eine Datenbank.

Ein Beispiel zum Extrahieren von Informationen zum Zielkontext aus dem HTTP-Kontext einer Anwendung finden Sie im Paket DefaultHttpTargetingContextAccessor innerhalb des Microsoft.FeatureManagement.AspNetCore-Pakets. Es extrahiert die folgenden Informationen:

  • Adressierung von Informationen aus der HttpContext.User-Eigenschaft
  • UserId Informationen aus dem Identity.Name Feld
  • Groups Informationen aus Ansprüchen vom Typ Role

Diese Implementierung basiert auf der Verwendung von IHttpContextAccessor. Weitere Informationen IHttpContextAccessorfinden Sie weiter oben in diesem Artikel unter Verwenden von HttpContext.

Zielbestimmung in einer Konsolenanwendung

Der Zielfilter basiert auf einem Zielkontext, um zu bewerten, ob ein Feature aktiviert werden soll. Dieser Zielkontext enthält Informationen wie den Benutzer, der ausgewertet wird, und die Gruppen, zu denen der Benutzer gehört. In Konsolenanwendungen steht in der Regel kein Umgebungskontext zum Übergeben dieser Informationen an den Zielfilter zur Verfügung. Daher müssen Sie dies direkt übergeben, wenn Sie FeatureManager.IsEnabledAsync aufrufen. Dieser Kontexttyp wird mithilfe von ContextualTargetingFilter. Anwendungen, die den Zielkontext an den Feature-Manager senden müssen, sollten ContextualTargetingFilter anstelle von TargetingFilter.

Da ContextualTargetingFilterIContextualTargetingFilter<ITargetingContext> implementiert, müssen Sie eine Implementierung von ITargetingContext an IVariantFeatureManager.IsEnabledAsync übergeben, damit es ein Feature auswerten und aktivieren kann.

IVariantFeatureManager fm;
…
// The userId and groups variables are defined earlier in the application.
TargetingContext targetingContext = new TargetingContext
{
   UserId = userId,
   Groups = groups
};

await fm.IsEnabledAsync(featureName, targetingContext);

ContextualTargetingFilter verwendet den Featurefilteralias Microsoft.Targeting, sodass die Konfiguration für diesen Filter mit den Informationen in Microsoft.Targeting, weiter oben in diesem Artikel, konsistent ist.

Ein Beispiel für die Verwendung von ContextualTargetingFilter in einer Konsolenanwendung finden Sie im Beispielprojekt "TargetingConsoleApp".

Gezielte Bewertungsmöglichkeiten

Optionen stehen zur Verfügung, um anzupassen, wie die Zielauswertung für alle Features ausgeführt wird. Sie können diese Optionen konfigurieren, wenn Sie die Featureverwaltung einrichten.

services.Configure<TargetingEvaluationOptions>(options =>
{
    options.IgnoreCase = true;
});

Zielausschluss

Wenn Sie eine Benutzergruppe definieren, können Sie Benutzer und Gruppen von der Zielgruppe ausschließen. Diese Funktionalität ist nützlich, wenn Sie ein Feature für eine Gruppe von Benutzern bereitstellen, aber sie müssen einige Benutzer oder Gruppen aus dem Rollout ausschließen. Um auszuschließende Benutzer und Gruppen anzugeben, verwenden Sie die Exclusion Eigenschaft einer Zielgruppe.

"Audience": {
    "Users": [
        "Jeff",
        "Alicia"
    ],
    "Groups": [
        {
            "Name": "Ring0",
            "RolloutPercentage": 100
        }
    ],
    "DefaultRolloutPercentage": 0,
    "Exclusion": {
        "Users": [
            "Mark"
        ]
    }
}

Der vorangehende Code aktiviert ein Feature für Benutzer mit den Namen Jeff und Alicia. Das Feature ist auch für Benutzer in der Gruppe mit dem Namen Ring0aktiviert. Das Feature ist jedoch für den Benutzer mit dem Namen Markdeaktiviert, auch wenn sich dieser Benutzer in der Ring0 Gruppe befindet. Ausschlüsse haben Vorrang vor dem Rest des Zielfilters.

Varianten

Manchmal verfügt das Feature über mehrere vorgeschlagene Entwurfsoptionen, wenn Sie einer Anwendung ein neues Feature hinzufügen. A/B-Tests bieten eine gemeinsame Lösung für die Entscheidung über ein Design. A/B-Tests umfassen die Bereitstellung einer anderen Version des Features für verschiedene Segmente der Benutzerbasis und dann die Auswahl einer Version basierend auf der Benutzerinteraktion. In der .NET-Featureverwaltungsbibliothek können Sie A/B-Tests mithilfe von Varianten implementieren, um verschiedene Konfigurationen eines Features darzustellen.

Varianten bieten eine Möglichkeit für ein Featureflag, mehr als ein einfaches Ein-/Aus-Flag zu werden. Eine Variante stellt einen Wert eines Featureflags dar, das eine Zeichenfolge, eine Zahl, ein boolescher Wert oder sogar ein Konfigurationsobjekt sein kann. Ein Featurekennzeichen, das Varianten deklariert, sollte die Umstände definieren, unter denen jede Variante verwendet werden soll. Weitere Informationen finden Sie unter "Varianten zuordnen" weiter unten in diesem Artikel.

public class Variant
{
    /// <summary>
    /// The name of the variant
    /// </summary>
    public string Name { get; set; }

    /// <summary>
    /// The configuration of the variant
    /// </summary>
    public IConfigurationSection Configuration { get; set; }
}

Varianten abrufen

Für jedes Feature können Sie eine Variante mithilfe der GetVariantAsync Methode der IVariantFeatureManager Schnittstelle abrufen.

…
IVariantFeatureManager featureManager;
…
Variant variant = await featureManager.GetVariantAsync("MyVariantFeatureFlag", CancellationToken.None);

IConfigurationSection variantConfiguration = variant.Configuration;

// Do something with the resulting variant and its configuration.

Nachdem Sie eine Variante abgerufen haben, können Sie die Konfiguration direkt als Implementierung von IConfigurationSection aus der Configuration-Eigenschaft der Variante verwenden. Eine weitere Option besteht darin, die Konfiguration mithilfe des .NET-Konfigurationsbindungsmusters an ein Objekt zu binden.

IConfigurationSection variantConfiguration = variant.Configuration;

MyFeatureSettings settings = new MyFeatureSettings();

variantConfiguration.Bind(settings);

Die zurückgegebene Variante hängt vom Benutzer ab, der ausgewertet wird. Sie können Informationen über den Benutzer aus einer Instanz von TargetingContext. Sie können diesen Kontext übergeben, wenn Sie GetVariantAsync aufrufen. Dies kann auch automatisch von einer Implementierung von ITargetingContextAccessor abgerufen werden, falls eine registriert ist.

Deklaration von Variantenfeatureflags

Im Vergleich zu Standardfeature-Flags weisen Variantenfeature-Flags zwei zusätzliche Eigenschaften auf: variants und allocation. Die variants Eigenschaft ist ein Array, das die für das Feature definierten Varianten enthält. Die allocation-Eigenschaft definiert, wie diese Varianten für das Feature zugewiesen werden sollen. Genau wie beim Deklarieren von Standardfeaturekennzeichnungen können Sie Variantenfeature-Flags in einer JSON-Datei einrichten. Der folgende Code ist ein Beispiel für ein Variant-Feature-Flag:

{
    "feature_management": {
        "feature_flags": [
            {
                "id": "MyVariantFeatureFlag",
                "enabled": true,
                "allocation": {
                    "default_when_enabled": "Small",
                    "group": [
                        {
                            "variant": "Big",
                            "groups": [
                                "Ring1"
                            ]
                        }
                    ]
                },
                "variants": [
                    { 
                        "name": "Big"
                    },  
                    { 
                        "name": "Small"
                    } 
                ]
            }
        ]
    }
}

Definieren von Varianten

Jede Variante verfügt über zwei Eigenschaften: einen Namen und eine Konfiguration. Der Name wird verwendet, um auf eine bestimmte Variante zu verweisen, und die Konfiguration ist der Wert dieser Variante. Sie können die configuration_value Eigenschaft verwenden, um die Konfiguration anzugeben. Die configuration_value Eigenschaft ist eine Inlinekonfiguration, die eine Zeichenfolge, eine Zahl, ein boolescher Wert oder ein Konfigurationsobjekt sein kann. Wenn Sie die Eigenschaft configuration_value nicht konfigurieren, wird die Eigenschaft Configuration der zurückgegebenen Variante null sein.

Um alle möglichen Varianten für ein Feature anzugeben, listen Sie sie unter der variants Eigenschaft auf.

{
    "feature_management": {
        "feature_flags": [
            {
                "id": "MyVariantFeatureFlag",
                "variants": [
                    { 
                        "name": "Big", 
                        "configuration_value": {
                            "Size": 500
                        }
                    },  
                    { 
                        "name": "Small", 
                        "configuration_value": {
                            "Size": 300
                        }
                    } 
                ]
            }
        ]
    }
}

Zuordnen von Varianten

Um die Varianten eines Features zuzuweisen, verwenden Sie die allocation Eigenschaft des Features.

"allocation": { 
    "default_when_enabled": "Small", 
    "default_when_disabled": "Small",  
    "user": [ 
        { 
            "variant": "Big", 
            "users": [ 
                "Marsha" 
            ] 
        } 
    ], 
    "group": [ 
        { 
            "variant": "Big", 
            "groups": [ 
                "Ring1" 
            ] 
        } 
    ],
    "percentile": [ 
        { 
            "variant": "Big", 
            "from": 0, 
            "to": 10 
        } 
    ], 
    "seed": "13973240" 
},
"variants": [
    { 
        "name": "Big", 
        "configuration_value": "500px"
    },  
    { 
        "name": "Small", 
        "configuration_value": "300px"
    } 
]

Die allocation Einstellung weist die folgenden Eigenschaften auf:

Eigenschaft BESCHREIBUNG
default_when_disabled Die Variante, die verwendet werden soll, wenn eine Variante angefordert wird, während das Feature als deaktiviert betrachtet wird.
default_when_enabled Die Variante, die verwendet werden soll, wenn eine Variante angefordert wird, während das Feature als aktiviert betrachtet wird und dem Benutzer keine andere Variante zugewiesen wird.
user Eine Variante und eine Liste der Benutzer, der die Variante zugewiesen werden soll.
group Eine Variante und eine Liste von Gruppen. Die Variante wird zugewiesen, wenn sich der aktuelle Benutzer in mindestens einer der Gruppen befindet.
percentile Eine Variante und ein Prozentbereich, in den der berechnete Prozentsatz des Benutzers passt, damit die Variante zugewiesen werden kann.
seed Der Wert, dem prozentuale Berechnungen für percentile zugrunde liegen. Die Prozentuale Berechnung für einen bestimmten Benutzer ist für alle Features gleich, wenn derselbe seed Wert verwendet wird. Wenn kein seed Wert angegeben wird, wird ein Standard-Seed basierend auf dem Featurenamen erstellt.

Wenn ein Feature nicht aktiviert ist, weist der Feature-Manager dem aktuellen Benutzer die angegebene default_when_disabled Variante zu. Im vorherigen Beispiel wird dieses Feature Small genannt.

Wenn das Feature aktiviert ist, prüft der Feature-Manager die Zuweisungen von user, group und percentile in dieser Reihenfolge, um eine Variante zuzuweisen. Im vorherigen Beispiel wird der angegebene Variant dem BigBenutzer in den folgenden Fällen zugewiesen:

  • Der benutzer, der ausgewertet wird, wird benannt Marsha.
  • Der Benutzer befindet sich in der Ring1 Gruppe.
  • Der Benutzer befindet sich zwischen dem nullten und zehnten Perzentil.

Wenn keine dieser Zuordnungen übereinstimmt, wird die default_when_enabled Variante dem Benutzer zugewiesen. Im Beispiel lautet Smalldiese Variante .

Die Zuordnungslogik ähnelt der Logik, die Sie für den Featurefilter "Microsoft.Targeting " verwenden. Es gibt jedoch einige Parameter, die in der Zielbestimmung vorhanden sind, die nicht in der Zuordnung enthalten sind, und umgekehrt. Die Ziel- und Zuordnungsergebnisse hängen nicht zusammen.

Hinweis

Um Featurevarianten zuzuweisen, müssen Sie ITargetingContextAccessor registrieren, indem Sie die WithTargeting<T>-Methode aufrufen.

Überschreiben des aktivierten Zustands mithilfe einer Variante

Sie können Varianten verwenden, um den aktivierten Status einer Featurekennzeichnung außer Kraft zu setzen. Wenn Sie diese Funktionalität nutzen, können Sie die Auswertung einer Featurekennzeichnung erweitern. Beim Aufruf von IsEnabledAsync mit einem Flag mit Varianten überprüft der Featureverwalter, ob die dem aktuellen Benutzer zugewiesene Variante so konfiguriert ist, dass sie das Ergebnis überschreibt.

Sie können das Überladen mithilfe der optionalen Variant-Eigenschaft status_override implementieren. Diese Eigenschaft kann die folgenden Werte aufweisen:

  • None: Die Variante wirkt sich nicht darauf aus, ob das Flag als aktiviert oder deaktiviert betrachtet wird. Der Standardwert lautet None.
  • Enabled: Wenn die Variante ausgewählt wird, wird das Feature-Flag als aktiviert ausgewertet.
  • Disabled: Wenn die Variante ausgewählt wird, wird das Feature-Flag als deaktiviert ausgewertet.

Sie können ein Feature nicht außer Kraft setzen, wenn es sich im enabled-Zustand von false befindet.

Wenn Sie ein Feature-Flag mit binären Varianten verwenden, kann die status_override Eigenschaft hilfreich sein. Sie können weiterhin APIs wie IsEnabledAsync und FeatureGateAttribute in Ihrer Anwendung verwenden. Sie können aber auch von den Funktionen profitieren, die mit Varianten einhergehen, wie z. B. Prozentverteilung und die Verwendung eines Startwerts für Prozentberechnungen.

{
    "id": "MyVariantFeatureFlag",
    "enabled": true,
    "allocation": {
        "percentile": [
            {
                "variant": "On",
                "from": 10,
                "to": 20
            }
        ],
        "default_when_enabled":  "Off",
        "seed": "Enhanced-Feature-Group"
    },
    "variants": [
        {
            "name": "On"
        },
        {
            "name": "Off",
            "status_override": "Disabled"
        }
    ]
}

Im vorherigen Beispiel ist das Feature immer aktiviert. Wenn sich der aktuelle Benutzer im berechneten Quantilbereich von 10 bis 20 befindet, wird die On Variante zurückgegeben. Andernfalls wird die Off Variante zurückgegeben, und da der status_override Wert lautet Disabled, wird das Feature als deaktiviert betrachtet.

Varianten in Abhängigkeitsinjektion

Sie können Variantenfeature-Flags zusammen mit der Abhängigkeitsinjektion verwenden, um unterschiedliche Implementierungen eines Diensts für verschiedene Benutzer verfügbar zu machen. Die IVariantServiceProvider<TService> Schnittstelle bietet eine Möglichkeit, diese Kombination zu erreichen.

IVariantServiceProvider<IAlgorithm> algorithmServiceProvider;
...

IAlgorithm forecastAlgorithm = await algorithmServiceProvider.GetServiceAsync(cancellationToken);

Im vorherigen Code ruft die IVariantServiceProvider<IAlgorithm> Implementierung eine Implementierung IAlgorithm aus dem Container zum Einfügen von Abhängigkeiten ab. Die gewählte Implementierung hängt von:

  • Das Feature-Flag, bei dem der IAlgorithm Dienst registriert ist.
  • Die zugewiesene Variante für dieses Feature.

Die IVariantServiceProvider<T> Implementierung wird der Anwendung durch das Aufrufen von IFeatureManagementBuilder.WithVariantService<T>(string featureName) verfügbar gemacht, wie das folgende Beispiel zeigt. Der Aufruf in diesem Code stellt IVariantServiceProvider<IAlgorithm> in der Dienstsammlung zur Verfügung.

services.AddFeatureManagement() 
        .WithVariantService<IAlgorithm>("ForecastAlgorithm");

Sie müssen jede Implementierung IAlgorithm separat über eine Add-Methode wie services.AddSingleton<IAlgorithm, SomeImplementation>() hinzufügen. Die Implementierung von IAlgorithm, die von IVariantServiceProvider verwendet wird, hängt vom Variantenfeatureflag ForecastAlgorithm ab. Wenn keine Implementierung von IAlgorithm der Dienstauflistung hinzugefügt wird, gibt IVariantServiceProvider<IAlgorithm>.GetServiceAsync() eine Aufgabe mit einem null-Ergebnis zurück.

{
    // The example variant feature flag
    "id": "ForecastAlgorithm",
    "enabled": true,
    "variants": [
        { 
            "Name": "AlgorithmBeta" 
        },
        ...
    ] 
}

Variant Services Alias-Attribut

Der Variant-Dienstanbieter verwendet die Typnamen von Implementierungen, um der zugeordneten Variante zu entsprechen. Wenn ein Variantendienst mit VariantServiceAliasAttributeversehen ist, sollte der in diesem Attribut deklarierte Name in der Konfiguration verwendet werden, um auf diesen Variantendienst zu verweisen.

[VariantServiceAlias("Beta")]
public class AlgorithmBeta : IAlgorithm
{
    ...
}

Telemetrie

Wenn Sie eine Featurekennzeichnungsänderung bereitstellen, ist es häufig wichtig, ihre Auswirkungen auf eine Anwendung zu analysieren. Hier sind beispielsweise einige Fragen, die auftreten können:

  • Sind die Flags wie erwartet aktiviert und deaktiviert?
  • Erhalten bestimmte Benutzer den Zugriff auf ein bestimmtes Feature wie erwartet?
  • Welche Variante sieht ein bestimmter Benutzer?

Die Ausgabe und Analyse von Featureflag-Auswertungsereignissen kann bei der Beantwortung dieser Art von Fragen helfen. Die .NET-Funktionsverwaltungsbibliothek verwendet die System.Diagnostics.Activity-API, um während der Auswertung des Featureflags Ablaufverfolgungstelemetriedaten zu erzeugen.

Telemetrie aktivieren

Standardmäßig werden keine Telemetriekennzeichnungen ausgegeben. Um Telemetrie für ein bestimmtes Featureflag zu veröffentlichen, MUSS das Flag deklarieren, dass es für die Telemetrieausgabe aktiviert ist.

Für in appsettings.jsondefinierte Featurekennzeichnungen können Sie telemetrie mithilfe der telemetry Eigenschaft aktivieren.

{
    "feature_management": {
        "feature_flags": [
            {
                "id": "MyFeatureFlag",
                "enabled": true,
                "telemetry": {
                    "enabled": true
                }
            }
        ]
    }
}

Der vorangehende Code aus einer appsettings.json-Datei definiert ein Featureflagge mit dem Namen MyFeatureFlag , das für Telemetrie aktiviert ist. Der Telemetriezustand wird durch das telemetry Objekt angegeben, das enabled auf true setzt. Der Wert der enabled-Eigenschaft muss true sein, um Telemetrie für die Kennzeichnung zu veröffentlichen.

Der telemetry-Abschnitt einer Featurekennzeichnung weist die folgenden Eigenschaften auf:

Eigenschaft BESCHREIBUNG
enabled Ein boolescher Wert, der angibt, ob Telemetrie für das Feature-Flag veröffentlicht werden soll.
metadata Eine Sammlung von Schlüsselwertpaaren, die als Wörterbuch modelliert werden, mit der Sie benutzerdefinierte Metadaten zum Feature-Flag an Auswertungsereignisse anfügen können.

Benutzerdefinierter Telemetriedatenherausgeber

Der Feature-Manager hat eine eigene ActivitySource Instanz mit dem Namen Microsoft.FeatureManagement. Wenn Telemetrie für ein Feature-Flag aktiviert ist:

  • Wenn eine Featurekennzeichnungsauswertung gestartet wird, startet der Feature-Manager eine Instanz von Activity.
  • Wenn eine Featurekennzeichnungsauswertung abgeschlossen ist, fügt der Feature-Manager eine ActivityEvent Instanz mit dem Namen FeatureFlag der aktuellen Aktivität hinzu.

Das FeatureFlag Ereignis enthält Tags, die Informationen über die Auswertung des Feature-Flags enthalten. Die Tags verwenden die im FeatureEvaluationEvent-Schema definierten Felder.

Hinweis

Alle Schlüssel-Wert-Paare, die in der telemetry.metadata-Eigenschaft des Feature-Flags angegeben sind, sind ebenfalls in den Tags enthalten.

Zum Aktivieren der benutzerdefinierten Telemetriedatenveröffentlichung können Sie eine Instanz von ActivityListener erstellen und auf der Aktivitätsquelle Microsoft.FeatureManagement lauschen. Der folgende Code zeigt, wie Sie die Quelle der Feature-Management-Aktivitäten überwachen und ein Callback hinzufügen, wenn ein Feature ausgewertet wird.

ActivitySource.AddActivityListener(new ActivityListener()
{
    ShouldListenTo = (activitySource) => activitySource.Name == "Microsoft.FeatureManagement",
    Sample = (ref ActivityCreationOptions<ActivityContext> options) => ActivitySamplingResult.AllData,
    ActivityStopped = (activity) =>
    {
        ActivityEvent? evaluationEvent = activity.Events.FirstOrDefault((activityEvent) => activityEvent.Name == "FeatureFlag");

        if (evaluationEvent.HasValue && evaluationEvent.Value.Tags.Any())
        {
            // Do something.
        }
    }
});

Weitere Informationen finden Sie unter Sammeln einer verteilten Ablaufverfolgung.

Application Insights-Telemetrie

Das Microsoft.FeatureManagement.Telemetry.ApplicationInsights-Paket bietet einen integrierten Telemetriedatenherausgeber, der Auswertungsdaten des Featureflags an Application Insights sendet. Das Microsoft.FeatureManagement.Telemetry.ApplicationInsights Paket stellt außerdem einen Telemetrieinitialisierer bereit, mit dem automatisch alle Ereignisse mit TargetingId markiert werden, sodass Ereignisse mit Flaggenbewertungen verknüpft werden können. Um diese Funktionalität nutzen zu können, fügen Sie einen Verweis auf das Paket hinzu, und registrieren Sie die Application Insights-Telemetrie. Der folgende Code gibt ein Beispiel:

builder.services
    .AddFeatureManagement()
    .AddApplicationInsightsTelemetry();

Hinweis

Um sicherzustellen, dass application Insights-Telemetrie erwartungsgemäß funktioniert, sollten Sie die TargetingHttpContextMiddleware Klasse verwenden.

Um die Persistenz des Zielkontexts in der aktuellen Aktivität zu aktivieren, können Sie die TargetingHttpContextMiddleware Klasse verwenden.

app.UseMiddleware<TargetingHttpContextMiddleware>();

Ein Beispiel für die Verwendung finden Sie im Beispiel VariantAndTelemetryDemo .

Voraussetzung

Der Telemetrieanbieter, den das Microsoft.FeatureManagement.Telemetry.ApplicationInsights Paket bereitstellt, erfordert, dass Application Insights als Anwendungsdienst registriert und eingerichtet wird. Beispielcode finden Sie in der Beispielanwendung VariantAndTelemetryDemo .

Caching

Der Featurestatus wird vom IConfiguration-System bereitgestellt. Es wird erwartet, dass Konfigurationsanbieter jegliche Zwischenspeicherung und dynamische Aktualisierungen verarbeiten. Der Feature-Manager fragt IConfiguration nach dem neuesten Wert des Status eines Features, wenn es auswertet, ob ein Feature aktiviert ist.

Momentaufnahme

In einigen Szenarien muss der Status eines Features während der Lebensdauer einer Anforderung konsistent bleiben. Die Werte, die von einer Standardimplementierung IVariantFeatureManager zurückgegeben werden, können sich ändern, wenn die Quelle IConfiguration, aus der sie stammen, während der Anforderung aktualisiert wird.

Sie können dieses Verhalten mithilfe von IVariantFeatureManagerSnapshot verhindern. Sie können IVariantFeatureManagerSnapshot auf die gleiche Weise wie IVariantFeatureManager abrufen. IVariantFeatureManagerSnapshot implementiert die IVariantFeatureManager Schnittstelle, aber IVariantFeatureManagerSnapshot zwischenspeichert den ersten ausgewerteten Status eines Features während einer Anforderung. Dieser Zustand wird während der Lebensdauer des Features zurückgegeben.

Benutzerdefinierte Funktionsanbieter

Wenn Sie einen benutzerdefinierten Featureanbieter implementieren, können Sie Featurekennzeichnungen aus Quellen wie einer Datenbank oder einem Featureverwaltungsdienst abrufen. Der Standardmäßige Featureanbieter ruft Featurekennzeichnungen aus dem .NET Core-Konfigurationssystem ab. Dieses System bietet Unterstützung für das Definieren von Features in einer appsettings.json-Datei oder in Konfigurationsanbietern wie Azure App Configuration. Sie können dieses Verhalten anpassen, um zu steuern, wo Featuredefinitionen gelesen werden.

Um das Laden von Featuredefinitionen anzupassen, müssen Sie die IFeatureDefinitionProvider Schnittstelle implementieren.

public interface IFeatureDefinitionProvider
{
    Task<FeatureDefinition> GetFeatureDefinitionAsync(string featureName);

    IAsyncEnumerable<FeatureDefinition> GetAllFeatureDefinitionsAsync();
}

Um eine Implementierung von IFeatureDefinitionProvider zu verwenden, müssen Sie sie der Dienstesammlung hinzufügen, bevor Sie das Feature-Management hinzufügen. Im folgenden Beispiel wird eine Implementierung von IFeatureDefinitionProvider namens InMemoryFeatureDefinitionProvider hinzugefügt.

services.AddSingleton<IFeatureDefinitionProvider, InMemoryFeatureDefinitionProvider>()
        .AddFeatureManagement()

Nächste Schritte

Informationen zur Verwendung von Featurekennzeichnungen in Ihren Anwendungen finden Sie in den folgenden Schnellstarts:

ASP.NET Core

.NET/.NET Framework-Konsolen-App

.NET Hintergrunddienst

Informationen zur Verwendung von Featurefiltern finden Sie in den folgenden Lernprogrammen:

Aktivieren bedingter Features mit Featurefiltern

Aktivieren von Features nach einem Zeitplan

Rollout von Features für Zielgruppen

  • Last updated on