NU1510 in .NET 11: Fix Microsoft.Extensions References Safely

NU1510 in .NET 11 can appear after upgrading a console app or library that explicitly references Microsoft.Extensions.Logging.Abstractions. For a project targeting only net11.0, remove that redundant reference and verify restore, build, and runtime behavior. If you also target .NET 10, keep the dependency for that target; the runnable example below shows both paths using a verified .NET 11 RC1 test.

Fix NU1510 in .NET 11

In the tested Before project, the explicit reference is the only package entry. The sample pins an RC1 package to make the reproduction concrete; do not copy that version into an unrelated production project as an upgrade recommendation.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net11.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="11.0.0-rc.1.26425.128" />
  </ItemGroup>

</Project>

The fix in After.csproj removes that ItemGroup entirely. The target remains net11.0, and the application code stays the same:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net11.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

This small app uses ILogger and NullLogger without restoring an explicit logging-abstractions package. The console marker makes the runtime check observable; NullLogger itself deliberately discards log messages, so this is not a test of console logging configuration.

using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Logging.Abstractions;

ILogger logger = NullLogger.Instance;
logger.LogInformation("This call proves the logging abstraction API compiles.");

Console.WriteLine("APP PASS: ILogger is available from the .NET 11 shared framework");

Remove the reference named by the diagnostic, rather than deleting every package whose name starts with Microsoft.Extensions. The change applies to a specific set of framework-provided libraries, and packages outside that set may still be required.

Which packages changed?

NU1510 predates .NET 11: the .NET 10 SDK introduced the warning for redundant direct references under package pruning. The additional .NET 11 change is that these nine libraries joined the base shared framework:

• Microsoft.Extensions.Caching.Abstractions
• Microsoft.Extensions.Configuration.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Diagnostics.Abstractions
• Microsoft.Extensions.FileProviders.Abstractions
• Microsoft.Extensions.Hosting.Abstractions
• Microsoft.Extensions.Logging.Abstractions
• Microsoft.Extensions.Options
• Microsoft.Extensions.Primitives

Microsoft documents this change from .NET 11 Preview 4. Its compatibility guidance covers the affected libraries and dependent-binary risks. The reproduction here tests one member of that set, not all nine.

The NuGet diagnostic means the direct reference is redundant for the applicable targets. It is different from a vulnerable-package warning; use the NuGet Audit CI workflow when the problem is a security advisory rather than dependency cleanup.

Verify the before and after behavior

The supplied Windows run selected SDK 11.0.100-rc.1.26425.128. From the demo directory, the following commands reproduce its verification sequence and save the full output to artifacts\verification.txt:

Unblock-File .\Verify-NU1510.ps1
powershell -NoProfile -ExecutionPolicy Bypass -File .\Verify-NU1510.ps1

The script checks command exit codes as well as diagnostics. Its Before restore must emit NU1510; the fixed project must restore and build without that diagnostic, then run successfully. Here are the equivalent commands for inspecting those stages individually from the demo directory:

dotnet --version
dotnet restore .\Before\Before.csproj --force --no-cache --verbosity minimal
dotnet restore .\After\After.csproj --force --no-cache --verbosity minimal
dotnet build .\After\After.csproj --configuration Release --no-restore --verbosity minimal
dotnet run --project .\After\After.csproj --configuration Release --no-build

The successful Windows output included these markers. The fixed build reported zero warnings and zero errors; its NETSDK1057 message identified the SDK as a preview and did not fail the build.

PASS: Before project emits NU1510
PASS: After project restores and builds without NU1510
APP PASS: ILogger is available from the .NET 11 shared framework
PASS: net11.0 app runs without the explicit package reference

There is a useful trap when checking output automatically: the demo folder name also contains NU1510. Searching for that bare string produced a false failure even though the fixed restore was clean. The corrected PowerShell script matches a diagnostic followed by a colon:

$nu1510DiagnosticPattern = '\bNU1510\s*:'

if ($afterRestoreOutput -match $nu1510DiagnosticPattern) {
    throw 'Unexpected NU1510 was found in the After restore output.'
}

This expression prevents a path containing the warning number from being counted as a diagnostic. It works with the captured RC1 output; if a future tool changes diagnostic formatting, update the parser and rerun the proof rather than assuming a missing match proves success.

Keep the .NET 10 dependency

For the exact net10.0;net11.0 pair in the demo, keep the logging-abstractions package in a conditional ItemGroup. The condition is evaluated for each target, so the .NET 10 build retains its dependency while the .NET 11 build uses framework-provided APIs:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net10.0;net11.0</TargetFrameworks>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'net10.0'">
    <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="10.0.0" />
  </ItemGroup>

</Project>

The 10.0.0 package version is the version used by this minimal proof. Choose the supported, appropriate package version for your real application. If you add other targets, including platform-specific TFMs, review the condition for those targets instead of assuming this exact equality covers them.

The NU1510 reference explains that the warning is raised only when the reference can be removed for all applicable targets. An unconditional reference can therefore remain valid in a multi-target project when an older target needs it. The conditional form makes that intent explicit; it is not a mandatory fix for every multi-target application.

dotnet restore .\MultiTargetSafe\MultiTargetSafe.csproj --force --no-cache --verbosity minimal
dotnet build .\MultiTargetSafe\MultiTargetSafe.csproj --configuration Release --framework net10.0 --no-restore --verbosity minimal
dotnet build .\MultiTargetSafe\MultiTargetSafe.csproj --configuration Release --framework net11.0 --no-restore --verbosity minimal

Both framework builds succeeded in the Windows test with zero warnings and zero errors, and the restore had no NU1510 diagnostic. The script builds these two targets but does not run them; the runtime result above belongs to the separate After application.

PASS: MultiTargetSafe builds net10.0 and net11.0 without NU1510
PASS: NU1510 proof completed

Checks before changing a real project

Use the reproduction to confirm the mechanism, then apply a small change to your own project and run its tests. A console app compiling one API cannot establish that every dependent binary or deployment will work.

• Identify the exact package and all target frameworks before removing its reference. Keep dependencies needed by older targets.
• Check Directory.Build.props, imported project files, and central package configuration if the reference does not appear directly in the project you opened. Change the effective reference at its actual source.
• Rebuild dependent libraries and test the APIs they use. Microsoft warns that older binaries can expose MissingMethodException or TypeLoadException when moving to the newer framework libraries.
• If the application commits a lock file, regenerate and review it after the dependency change, then run its usual locked restore. Do not delete the lock file simply to make CI green.
• Keep the dependency edit in a separate commit so it can be reverted independently if your application checks fail. Validate your normal packaging and deployment path before rollout.

NuGet treats TreatWarningsAsErrors, WarningsAsErrors, and NoWarn differently. Hiding NU1510 can remove the visible symptom while leaving the redundant reference; prefer the tested project edit where it applies. For a separate problem in which vulnerability warnings block remediation, see updating vulnerable packages while retaining TreatWarningsAsErrors.

The Windows proof establishes the before/after warning, fixed application execution, and two successful target builds on one RC1 SDK. It does not measure performance, validate old binary compatibility, or test self-contained deployment and Native AOT. Recheck the behavior on the SDK and deployment configuration you intend to ship.

References

• Microsoft: Microsoft.Extensions libraries in the .NET 11 shared framework
• NuGet: NU1510 diagnostic and target-framework rules
• Microsoft: NU1510 introduced in .NET 10
• NuGet: conditional PackageReference, warning controls, and lock files

Demo source code: View the complete runnable example on GitHub.

Found this useful? Support more practical developer content.

Buy me a coffee PayPal