Target frameworks

NuGet uses target framework references in a variety of places to specifically identify and isolate framework-dependent components of a package:

• project file: For SDK-style projects, the .csproj contains the target framework references.
• .nuspec manifest: A package can indicate distinct packages to be included in a project depending on the project's target framework.
• .nupkg folder name: The folders inside a package's lib folder can be named according to the target framework, each of which contains the DLLs and other content appropriate to that framework.
• packages.config: The targetframework attribute of a dependency specifies the variant of a package to install.

For the canonical list of all supported target frameworks and their TFM syntax, see Target frameworks in SDK-style projects.

TargetFramework values are aliases

The TargetFramework property in a project file is a friendly name — an alias — that gets translated into a canonical framework identity. The .NET SDK performs this translation by setting the TargetFrameworkMoniker (TFM), and when applicable, the TargetPlatformMoniker properties.

For example, when you write <TargetFramework>net10.0-windows</TargetFramework>, the .NET SDK translates that into:

• TargetFrameworkMoniker = .NETCoreApp,Version=v10.0
• TargetPlatformMoniker = Windows,Version=7.0

NuGet uses these moniker properties — not the TargetFramework string — for package compatibility checks. This means the TargetFramework value itself can be any string, as long as the moniker properties are set correctly. For example, the following project is valid:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>banana</TargetFramework>
  </PropertyGroup>

  <PropertyGroup Condition=" '$(TargetFramework)' == 'banana' ">
    <TargetFrameworkIdentifier>.NETCoreApp</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v10.0</TargetFrameworkVersion>
    <TargetFrameworkMoniker>.NETCoreApp,Version=v10.0</TargetFrameworkMoniker>
  </PropertyGroup>
</Project>

This project restores and builds for .NET 10.0, even though the TargetFramework value is banana. The .NET SDK already relies on this aliasing mechanism for OS-specific TFMs like net8.0-ios and net8.0-android, where the short TFM is translated into the full moniker with platform information.

Multi-targeting with duplicate frameworks

Starting with NuGet 7.6 / .NET SDK 10.0.300, multiple TargetFrameworks aliases can resolve to the same effective framework. This enables scenarios like multi-RID builds and multi-version extension targeting. For details on how this works with restore, pack, lock files, and project references, see Targeting multiple frameworks.

Supported frameworks

A framework is typically referenced by a short target framework moniker or TFM. In .NET Standard this is also generalized to TxM to allow a single reference to multiple frameworks.

The NuGet clients support the frameworks in the table below. Equivalents are shown within brackets []. Note that some tools, such as dotnet, might use variations of canonical TFMs in some files. For example, dotnet pack uses .NETCoreApp2.0 in a .nuspec file rather than netcoreapp2.0. The various NuGet client tools handle these variations properly, but you should always use canonical TFMs when editing files directly.

Deprecated frameworks

The following frameworks are deprecated. Packages targeting these frameworks should migrate to the indicated replacements.

Precedence

A number of frameworks are related to and compatible with one another, but not necessarily equivalent:

NET Standard

.NET Standard simplifies references between binary-compatible frameworks, allowing a single target framework to reference a combination of others. (For background, see the .NET Primer.)

The NuGet Get Nearest Framework Tool simulates what NuGet uses to select one framework from many available framework assets in a package based on the project's framework.

The dotnet series of monikers should be used in NuGet 3.3 and earlier; the netstandard moniker syntax should be used in v3.4 and later.

Portable Class Libraries

To define a target framework that refers to multiple child-target-frameworks, the portable keyword use used to prefix the list of referenced frameworks. Avoid artificially including extra frameworks that are not directly compiled against because it can lead to unintended side-effects in those frameworks.

Additional frameworks defined by third parties provide compatibility with other environments that are accessible in this manner. Additionally, there are shorthand profile numbers that are available to reference these combinations of related frameworks as Profile#, but this is not a recommended practice to use these numbers as it reduces the readability of the folders and .nuspec.

Additionally, NuGet packages targeting Xamarin can use additional Xamarin-defined frameworks: