Experimentelle Features in .NET 9+
Ab .NET 9 verwenden einige Features die ExperimentalAttribute Möglichkeit, anzugeben, dass das API-Shape oder die API-Funktionalität in der Version enthalten ist, aber noch nicht offiziell unterstützt wird. Experimentelle Features ermöglichen es dem .NET-Team, Feedback zur Form und Funktionalität einer API zu sammeln, um die API zu verfeinern und das [Experimental]
Attribut in der nächsten Hauptversion zu entfernen.
Wenn Ihr Code auf eine experimentelle API verweist, erzeugt der Compiler einen Fehler mit einer ID wie SYSLIB5XXX
. Jedes Feature, das als experimentell gekennzeichnet ist, verfügt über eine eindeutige Diagnose-ID. Um die Verwendung eines experimentellen Features zum Ausdruck zu bringen, unterdrücken Sie die spezifische Diagnose. Dazu können Sie eine der Methoden zum Unterdrücken der Diagnose verwenden. Es wird jedoch empfohlen, die Diagnose zur <NoWarn>
-Eigenschaft des Projekts hinzuzufügen. Weitere Informationen finden Sie unter Unterdrücken von Warnungen.
Da jedes experimentelle Feature über eine separate ID verfügt, bedeutet die Zustimmung zur Nutzung einer experimentellen Funktion nicht die Zustimmung zur Nutzung einer anderen.
Verweis
Die folgende Tabelle enthält einen Index zu den SYSLIB5XXX
experimentellen APIs in .NET 9+.
Diagnose-ID | Experimentelle Version | Beschreibung |
---|---|---|
SYSLIB5001 | .NET 9 | Tensor<T>und zugehörige APIs sind experimentell.System.Numerics.Tensors |
SYSLIB5002 | .NET 9 | SystemColors Alternative Farben sind experimentell |
SYSLIB5003 | .NET 9 | Sve ist experimentell |
SYSLIB5004 | .NET 9 | DivRem(UInt32, Int32, Int32) ist experimentell, da die Leistung nicht so optimiert ist wie T.DivRem |
SYSLIB5005 | .NET 9 | System.Formats.Nrbf ist experimentell |
Unterdrücken von Warnungen
Wenn Sie ein experimentelles Feature verwenden, können Sie Feedback zu API-Shape und -Funktionen übermitteln, bevor das Feature als stabil und vollständig unterstützt markiert wird. Die Verwendung des Features erzeugt jedoch eine Warnung vom Compiler. Wenn Sie die Warnung unterdrücken, bestätigen Sie, dass sich das API-Shape oder die Funktionalität in der nächsten Hauptversion ändern kann. Die API kann sogar entfernt werden. Sie können die Warnung durch eine <NoWarn>
Projekteinstellung (empfohlen) oder eine #pragma
Direktive im Code unterdrücken.
So unterdrücken Sie die Warnungen in einer Projektdatei:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net9.0</TargetFramework>
<!-- NoWarn below suppresses SYSLIB5001 project-wide -->
<NoWarn>$(NoWarn);SYSLIB5001</NoWarn>
<!-- To suppress multiple warnings, you can use multiple NoWarn elements -->
<NoWarn>$(NoWarn);SYSLIB5002</NoWarn>
<NoWarn>$(NoWarn);SYSLIB5003</NoWarn>
<!-- Alternatively, you can suppress multiple warnings by using a semicolon-delimited list -->
<NoWarn>$(NoWarn);SYSLIB5001;SYSLIB5002;SYSLIB5003</NoWarn>
</PropertyGroup>
</Project>
So unterdrücken Sie die Warnungen im Code:
// Disable the warning.
#pragma warning disable SYSLIB5001
// Code that uses an experimental API that produces the diagnostic SYSLIB5001
//...
// Re-enable the warning.
#pragma warning restore SYSLIB5001