.NET Framework 4.7 app fails to load dependency from .NET Standard library due to NuGet selecting different assemblies

1 week ago 13
ARTICLE AD BOX

I have a solution with two projects:

A class library targeting .NET Standard 2.0

An application targeting .NET Framework 4.7

The .NET Standard library references a NuGet package that ships different assemblies for different target frameworks.
For example:

The .NET Standard folder in the package contains Assembly A

The .NET Framework folder contains Assembly B

These assemblies have different simple names.

The .NET Standard library is compiled against Assembly A, however the .NET Framework 4.7 application restores Assembly B, because NuGet automatically selects the .NETFramework asset group.

When running the application, I get:

Could not load file or assembly 'AssemblyA'

The reason is that Assembly A never appears in the application's output folder — only Assembly B is restored.

I also found this related announcement from Microsoft:
https://github.com/dotnet/announcements/issues/31

This issue describes how older dependency resolution behaviors can cause missing assets when mixing .NET Framework + .NET Standard + NuGet packages with different TFMs.


What I tried

Migrating the .NET Framework project to PackageReference

Cleaning/resetting bin/obj and rebuilding

Ensuring both projects reference the same version of the NuGet package

Removing the direct package reference in the application to rely on transitive restore

Checking if NuGet supports overriding asset selection (e.g., picking .NET Standard assets from a .NET Framework project)

NuGet consistently selects the .NETFramework assets for the .NET Framework 4.7 project, so only Assembly B is restored.


Question

Is there any supported way to make a .NET Framework 4.7 project use the .NET Standard assets of a NuGet package, so that the dependency expected by the .NET Standard library (Assembly A) is available at runtime?

Or is this scenario simply unsupported because:

NuGet chooses assets strictly based on the consuming project's target framework

The assemblies in each TFM folder have different names/identities

And therefore cannot be substituted via binding redirects or other mechanisms?

Read Entire Article