.NET Standard library output doesn't include nuget dependencies

Question

I have these three projects:

1. An ASP.NET Core MVC application (targeting .NET Framework 4.6.2)
2. A class library containing my EF Core Models, Migrations and DbContext classes (targeting .NET Standard 2.0, previously .NET Framework 4.6.2).
3. A console application for updating a database using EF Core Migrations (targeting .NET Framework 4.6.2).

Both 1 and 3 reference 2. I just replaced the old .NET Framework class library with a new one targeting .NET Standard. The class library uses the Microsoft.EntityFrameworkCore.Proxies NuGet package.

Everything builds without error, my unit tests all run, and the ASP.NET Core app runs without issue. My problem is that the console application for updating the database builds, runs, but encounters a runtime error when it initializes the DbContext on this line in the constructor:

ChangeTracker.LazyLoadingEnabled = false;

Saying that it cannot load the assembly Microsoft.EntityFrameworkCore.Proxies . On investigation I found that the Microsoft.EntityFrameworkCore.Proxies.dll file was not in the build output of the console application or the class library project. The only .dll in the output of the class library project was the project .dll itself, the old .NET Framework version had all the NuGet package .dlls in the output as well, and it ran fine using the database update tool.

Is there something extra that is necessary to include the dependencies in the output of a .NET Standard library?

Answer 1

Here is another suggestion, taken from CEZARY PIĄTEK's blog

 <Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>    
  </PropertyGroup>
</Project>

Answer 2

You might have to directly refer to something within that library to ensure the dependency walker sees types in there.

We actually needed to do with sometimes with Entity Framework SQL server at one point

private static readonly [proxylibnamespace].[somepublictype] _ProxyLibReference;

By doing that, sometimes the dependency walker sees a direct reference to a type and then includes it in a final build.

Answer 3

I ended up having to add .NET Framework 4.6.2 to the list of Target Frameworks for the class library.

In .csproj:

<PropertyGroup>
  <TargetFrameworks>netstandard2.0;net462</TargetFrameworks>
</PropertyGroup>

After this it works with a .NET Framework application.