dotnet build for .net 4.7 library fails citing missing references

[bradleypatton]

Steps to reproduce

I have a ASP.Net Core 2 web application with class libraries that target the .net 4.7 framework. Visual Studio compiles fine but dotnet build fails. I've tracked the errors down to the class libraries which I've switched to use. I've followed the workarounds here (dotnet/standard#481) and switched the library to use PackageReferences in the .csproj file and remove the packages.config. After some initial issues VS compiles fine and nuget restore works without issue but dotnet build still fails.

Expected behavior

dotnet build succeeds.

Actual behavior

Multiple errors about missing assemblies (ie Nuget Package references).

ApplicationSupport\EmailConfiguration.cs(4,7): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?) [C:\Dev\Neptune\Neptune.Common\Neptune.Common.csproj]

Environment data

dotnet --info output:

.NET Command Line Tools (2.1.2)

Product Information:
Version: 2.1.2
Commit SHA-1 hash: 5695315

Runtime Environment:
OS Name: Windows
OS Version: 10.0.16299
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.2\

Microsoft .NET Core Shared Framework Host

Version : 2.0.3
Build : a9190d4a75f4a982ae4b4fa8d1a24526566c69df

[livarcocc]

Can you share a small repro with us or your project files?

cc @dsplaisted

[bradleypatton]

Yes I was surprised it's pretty easy to replicate. Sample code attached below.

1. Create a new Windows Classic Desktop -> Class Library (.Net Framework).
2. Add a reference to Newtonsoft Json.Net
3. Add a class and reference something in that package
4. Compile it fine in VS
5. Failed compile with dotnet build

C:\Dev\Dotnet\DotnetCompile>dotnet build
Microsoft (R) Build Engine version 15.5.179.9764 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restoring packages for C:\Dev\Dotnet\DotnetCompile\DotnetCompile.csproj...
  Restore completed in 72.88 ms for C:\Dev\Dotnet\DotnetCompile\DotnetCompile.csproj.
EmailConfiguration.cs(3,7): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?) [C:\Dev\Dotnet\DotnetCompile\DotnetCompile.csproj]

Build FAILED.

EmailConfiguration.cs(3,7): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?) [C:\Dev\Dotnet\DotnetCompile\DotnetCompile.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.87

DotnetCompile.zip

[livarcocc]

The dotnet cli does not support old style csproj files and does not support windows desktop projects, which is why it fails for you.

[bradleypatton]

That sucks. I got to this point because I created a new ASP.Net Core 2 web app but I have existing class libraries that use System.Drawing functionality and therefore I still need to target the full framework. Everything seems to work fine in VS except when I go to publish the app to Azure it doesn't find any DbContexts so Enable migrations checkbox is not shown. When I try to use the ef CLI to list the dbcontext it fails
dotnet ef dbcontext list -v

I followed the chain down I see the Build fails on the class libraries. So the issue in the UI is probably related to the mix of frameworks.

I guess I might have to try out 'System.Drawing for .NET Core 2.0' compatibility package and see if I can convert the class libraries.

It just sends a very confusing message when most of this is supported in the VS but not in the CL.

[livarcocc]

Unfortunately, not all the tooling that is available in VS is available in the CLI. There are many things in VS that are windows only and we try to maintain the CLI as portable across OSes as possible, but also, VS is simply ahead of the CLI in time.

I would recommend using msbuild.exe in the command line if you want to have a command line experience that can work with your projects. This works in MSBuild (likely) because that is the msbuild that comes with VS and as such has all the props/targets that implement this extra functionality on the VS side.

[bradleypatton]

My final thought on this matter. So I spent about a day converting over my class libraries to .net core (hacking and commenting around some System.Drawing issues) and got everything working. DbContexts and enable migrations checkbox now appears in the Web Publish settings so obviously that code was using the EF tools which were failing on the build.

I did notice in the CLI there are warnings for packages that don't have core versions but not build failures. I've attached a small sample project and dotnet output below. It seems to me that dotnet build could do the same whether the class library is targeting .net core or full framework.

Microsoft (R) Build Engine version 15.5.179.9764 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Dev\DotnetCore\CoreTest\CoreTest.csproj : warning NU1701: Package 'NLog 4.4.12' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.
  Restore completed in 17.16 ms for C:\Dev\DotnetCore\CoreTest\CoreTest.csproj.
C:\Dev\DotnetCore\CoreTest\CoreTest.csproj : warning NU1701: Package 'NLog 4.4.12' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.
  CoreTest -> C:\Dev\DotnetCore\CoreTest\bin\Debug\netcoreapp2.0\CoreTest.dll

Build succeeded.

C:\Dev\DotnetCore\CoreTest\CoreTest.csproj : warning NU1701: Package 'NLog 4.4.12' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.
C:\Dev\DotnetCore\CoreTest\CoreTest.csproj : warning NU1701: Package 'NLog 4.4.12' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.
    2 Warning(s)
    0 Error(s)

CoreTest.zip

[livarcocc]

@bradleypatton I am sorry, I don't follow your suggestion. What would you expect dotnet build to do?

[bradleypatton]

My suggestion or hope would be if dotnet could issue warnings rather than fail to build if it encounters framework assemblies (even if there are runtime errors later). The reason this is a big issue is that Visual Studio seems to support mixing full framework and .core packages. But then some functionality in VS breaks because under the covers it is calling dotnet and the cmdline is failing.

I'm in the process of trying to convert all of my code to .net core projects because I just don't see the mixed code working very well.

[krishnan-unni]

Not sure if anyone is still facing this issue without a solution. After some experiments I found out that the issue is with dotnet cli's having trouble restoring the nuget packages and referencing them properly for the old style projects. I have 2 solutions for this:

1. You can convert the old style csproj file to the new SDK style project file and build.
2. In case you can't or don't want to change the csproj file to the new style (due to its complexity of change or other reasons) you can change the nuget settings to use package.config (with project.json file) format instead of PackageReference format and then build. Dotnet cli would build fine.