Editja

Some Microsoft.Extensions packages included in shared framework

To reduce application size, simplify package dependencies, and streamline servicing, .NET 11 includes nine Microsoft.Extensions.* libraries in the base shared framework. Projects that explicitly reference these packages receive build warning NU1510. You can resolve the warning by removing the PackageReference. If you depend on an older version of these packages, upgrading to the .NET 11 version might expose breaking changes introduced between older versions and .NET 11.

Version introduced

.NET 11 Preview 4

Previous behavior

Previously, the following Microsoft.Extensions.* libraries weren't part of the .NET shared framework. (You get the shared framework by using Sdk="Microsoft.NET.Sdk", or similarly referencing any of the other .NET SDKs.) Projects that needed them required explicit PackageReference entries, and the build process copied the assemblies to the output folder:

New behavior

Starting in .NET 11, these nine libraries are part of the .NET base shared framework:

  • You don't need a PackageReference for these libraries when you target net11.0 or later.
  • If you reference these packages explicitly, you receive build warning NU1510.
  • These assemblies are no longer copied to the output folder.
  • In rare cases, the additional APIs in the default load set might cause name or type conflicts. To resolve a conflict, add more explicit using directives, use an alias, or use a fully qualified type name.

Type of breaking change

This change is a behavioral change.

Reason for change

Including these commonly used libraries in the shared framework reduces application size, simplifies package dependencies, and streamlines servicing.

Remove the PackageReference for any affected package:

For projects that target only net11.0 or later, remove the PackageReference entirely:

<!-- Remove entries like these from your .csproj when targeting net11.0 only: -->
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="..." />
<PackageReference Include="Microsoft.Extensions.Options" Version="..." />

Your code continues to work without modification—the APIs are now part of the runtime.

For multi-targeted projects (for example, <TargetFrameworks>net10.0;net11.0</TargetFrameworks>), NU1510 isn't raised because the package is still required for the older TFM. No action is required—NuGet selects the appropriate assembly for each target framework automatically. If you want to be explicit, you can conditionally include the reference:

<!-- Keep the reference only for TFMs that don't include it in the shared framework: -->
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="..." Condition="'$(TargetFramework)' != 'net11.0'" />

Resolve compile-time name conflicts (rare):

If you encounter a compile error because a name in your code conflicts with one of the newly included APIs, use one of these approaches:

  • Add a more specific using directive.
  • Use a using alias.
  • Use a fully qualified type name.

If you depend on an older version of these packages:

To avoid runtime failures like MissingMethodException or TypeLoadException, recompile any dependent libraries or binaries against the .NET 11 reference assemblies. If you target net11.0, remove the PackageReference and rebuild. If you target earlier TFMs or multi-target, update the package references for the non-net11.0 targets to the current version, and then recompile.

The following breaking changes from previous versions might surface when upgrading to the .NET 11 versions of these packages:

Microsoft.Extensions.DependencyInjection.Abstractions

Microsoft.Extensions.Logging.Abstractions

Microsoft.Extensions.Hosting.Abstractions

Affected APIs

None.

  • Last updated on