|
| 1 | +--- |
| 2 | +title: Preview APIs |
| 3 | +description: Learn how to mark .NET APIs as preview. |
| 4 | +ms.date: 01/27/2025 |
| 5 | +--- |
| 6 | + |
| 7 | +# Preview APIs |
| 8 | + |
| 9 | +The .NET platform takes compatibility seriously. As such, the library ecosystem tends to avoid making breaking changes, especially with respect to the API. |
| 10 | + |
| 11 | +Nonetheless, when designing APIs, it's important to be able to collect feedback from users and make changes to the API based on that feedback if necessary. To avoid surprises, you should understand which APIs you use are considered stable and which ones are still in active development and might change. |
| 12 | + |
| 13 | +There are multiple ways an API can express that it's in preview form: |
| 14 | + |
| 15 | +* The entire component is considered preview if it's exposed: |
| 16 | + |
| 17 | + * In a preview release of the .NET runtime. |
| 18 | + * In a prerelease NuGet package. |
| 19 | + |
| 20 | +* An otherwise stable component marks specific APIs as preview with the following attributes: |
| 21 | + |
| 22 | + * <xref:System.Runtime.Versioning.RequiresPreviewFeaturesAttribute> |
| 23 | + * <xref:System.Diagnostics.CodeAnalysis.ExperimentalAttribute> |
| 24 | + |
| 25 | +This article explains how each option works, and, for library developers, how to choose between these options. |
| 26 | + |
| 27 | +## .NET runtime previews |
| 28 | + |
| 29 | +With the exception of release candidates (RCs) with a go-live license, preview versions of the .NET runtime and SDK aren't supported. |
| 30 | + |
| 31 | +As such, any APIs added as part of a .NET preview are considered subject to change, based on feedback the previews receive. To use a .NET runtime preview, you need to explicitly target a newer framework version in your project. By doing so, you implicitly express consent to consume APIs that might change. |
| 32 | + |
| 33 | +## Prerelease NuGet packages |
| 34 | + |
| 35 | +NuGet packages can either be stable or *prerelease*. Prerelease packages are marked as such with a prerelease suffix on their version. For example, `System.Text.Json 9.0.0-preview.2.24128.5` has a prerelease suffix of `preview.2.24128.5`. |
| 36 | + |
| 37 | +Prerelease packages are commonly used as a means to collect feedback from early adopters. They are generally unsupported by their author. |
| 38 | + |
| 39 | +When you install a package, either via the CLI or UI, you must explicitly indicate whether you want to install a prerelease version. By doing so, you implicitly express consent to consume APIs that might change. |
| 40 | + |
| 41 | +## `RequiresPreviewFeaturesAttribute` |
| 42 | + |
| 43 | +The <xref:System.Runtime.Versioning.RequiresPreviewFeaturesAttribute> attribute is used for APIs that require preview behaviors across the stack, including the runtime, the C# compiler, and libraries. When you consume APIs marked with this attribute, you'll receive a build error unless your project file includes the property `<EnablePreviewFeatures>true</EnablePreviewFeatures>`. Setting that property to `true` also sets `<LangVersion>Preview</LangVersion>`, which allows the use of preview language features. |
| 44 | + |
| 45 | +As an example, in .NET 6 the *generic math* library was marked with <xref:System.Runtime.Versioning.RequiresPreviewFeaturesAttribute> because it required static interface members, which were in preview at the time. |
| 46 | + |
| 47 | +## `ExperimentalAttribute` |
| 48 | + |
| 49 | +.NET 8 added <xref:System.Diagnostics.CodeAnalysis.ExperimentalAttribute>, which doesn't require any runtime or language preview features and simply indicates that a given API isn't stable yet. |
| 50 | + |
| 51 | +When building against an experimental API, the compiler produces an error. Each feature that's marked as experimental has its own separate diagnostic ID. To express consent to using an experimental API, you suppress the specific diagnostic. You can do that via any of the means for suppressing diagnostics, but the recommended way is to add the diagnostic to the project's `<NoWarn>` property. |
| 52 | + |
| 53 | +Since each experimental feature has a separate ID, consenting to using one experimental feature doesn't consent to using another. |
| 54 | + |
| 55 | +For more information, see [Experimental features][experimental-overview]. |
| 56 | + |
| 57 | +## Guidance for library developers |
| 58 | + |
| 59 | +Library developers should generally express that an API is in preview in one of two ways: |
| 60 | + |
| 61 | +* For new APIs introduced in a *prerelease* version of your package, you don't need to do anything; the package already expresses preview quality. |
| 62 | +* If you want to ship a stable package that contains some preview quality APIs, you should mark those APIs using `[Experimental]`. Make sure to use [your own diagnostic ID][choosing-diagnostic-ids] and make it specific to those features. If you have multiple independent features, consider using multiple IDs. |
| 63 | + |
| 64 | +The `[RequiresPreviewFeatures]` attribute is only meant for components of the .NET platform itself. Even there, it's only used for APIs that require runtime and language preview features. If it's just an API that's in preview, the .NET platform uses the `[Experimental]` attribute. |
| 65 | + |
| 66 | +The exception to this rule is if you're building a stable library and want to expose certain features that in turn depend on runtime or language preview behaviors. In that case, you should use `[RequiresPreviewFeatures]` for the entry points of that feature. However, you need to consider that users of such APIs have to turn on preview features too, which exposes them to all runtime, library, and language preview behaviors. |
| 67 | + |
| 68 | +[choosing-diagnostic-ids]: ../../csharp/roslyn-sdk/choosing-diagnostic-ids.md |
| 69 | +[experimental-overview]: ../syslib-diagnostics/experimental-overview.md |
0 commit comments