4

Setup

Say I have a .Net Standard 2.0 class library project and I add a Nu NuGet package that is compatible with .Net Standard 2.0 to it.

I then reference that class library project from both a .Net Framework console project and a .Net Core console project.

To restate with a picture:

NuGet Via a DLL

Question

How does each of the console applications deal with getting the right NuGet code for their type of application?

Notes

Note: I tried this using Microsoft.Extensions.DependencyInjection, and it works fine in the .Net Core 3.1 console app, but throws a "File Not Found" exception in the .Net Framework 4.7.2 console app (looking for the Dependency Injection DLL). This leads me to believe that .Net Standard 2.0 NuGets are really .Net Core NuGets...

Note to the Note: I am trying to understand what happens here, not fix the "File Not Found" issue. (That is easily fixable by referencing the Microsoft.Extensions.DependencyInjection NuGet in the .Net Framework 4.7.2 console app).

Vaccano
  • 78,325
  • 149
  • 468
  • 850
  • This should be caused by the .NET Framework project system. Maybe this helps: https://www.hanselman.com/blog/ReferencingNETStandardAssembliesFromBothNETCoreAndNETFramework.aspx – Christian Held Jun 05 '20 at 19:20
  • Does your .NET Framework console project have any PackageReferences? My guess is that it does not and so is not transitively finding the package dependency. I think if you add `PackageReference` to your .NET Framework console project in a PropertyGroup and run a restore then that should get msbuild to opt in to this behaviour. The RestoreProjectStyle is needed if the .NET Framework console project does not use any PackageReferences. – Matt Ward Jun 06 '20 at 13:23

1 Answers1

6

In your scenario two different package resolution startegies are used. There is the old way of managing packages with packages.config and the new way with PackageReferences. There is also the old project format of .NET Framework projects and the new SDK-style format that was introduced for .NET Core, but is also usable in .NET Framework applications.

With the old project format that is still used by most existing .NET Framework applications regardless of packages.config or PackageReference, the .NET Framework Console application is only able to access the class library, but not the assemblies of its referenced NuGet package, because it is not a direct reference but via your library, hence indirect. This is als called a transitive dependency.

In the new SDK-style project format with PackageReference, this is fundamentally different. There, transitive dependencies are possible. This means, that your .NET Framework console application can access the class library project, as well as its referenced assemblies via the NuGet package.

The SDK-style format with PackageReference is the default for .NET Core projects, so they support transitive dependencies out of the box. Only with the old project format you have to add NuGet packages manually, because it cannot access the transitive dependency through the class library. You can migrate existing .NET Framework projects to the new SDK-style format, to enable the same behavior as in .NET Core.

thatguy
  • 21,059
  • 6
  • 30
  • 40