Sdk: Can't build for net46 (net451, net452 works fine)

[moozzyk]

Steps to reproduce

Use the https://github.com/aspnet/cli-samples/tree/master/HelloMvc sample.
Add net46 as the target framework
Restore (restores fine)
Build (dotnet build -f net46)

Expected behavior

Project builds successfully

Actual behavior

PS C:\Source\cli-samples\HelloMvc> dotnet build -f net46
Project HelloMvc (.NETFramework,Version=v4.6) will be compiled because expected outputs are missing
Compiling HelloMvc for .NETFramework,Version=v4.6
C:\Source\cli-samples\HelloMvc\project.json(15,42): error NU1001: The dependency System.Diagnostics.FileVersionInfo >= 4.0.0-rc2-24027 could not be resolved.
C:\Source\cli-samples\HelloMvc\project.json(15,42): error NU1001: The dependency System.Diagnostics.StackTrace >= 4.0.1-rc2-24027 could not be resolved.
C:\Source\cli-samples\HelloMvc\project.json(15,42): error NU1001: The dependency System.Text.Encoding.CodePages >= 4.0.1-rc2-24027 could not be resolved.
C:\Source\cli-samples\HelloMvc\project.json(15,42): error NU1001: The dependency System.Threading.Thread >= 4.0.0-rc2-24027 could not be resolved.
C:\Source\cli-samples\HelloMvc\project.json(15,42): error NU1001: The dependency System.Xml.XmlDocument >= 4.0.1-rc2-24027 could not be resolved.
C:\Source\cli-samples\HelloMvc\project.json(15,42): error NU1001: The dependency System.Xml.XPath.XDocument >= 4.0.1-rc2-24027 could not be resolved.

Compilation failed.
    0 Warning(s)
    6 Error(s)

Time elapsed 00:00:00.0945403

Note when targeting net451 or net452 the project builds just fine.

Environment data

dotnet --info output:

PS C:\Source\cli-samples\HelloMvc> dotnet --info
.NET Command Line Tools (1.0.0-rc2-002670)

Product Information:
 Version:     1.0.0-rc2-002670
 Commit Sha:  f0018642a9

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

[davidfowl]

Did you remove Microsoft.NETCore.App?

[moozzyk]

1. It works just fine for net451 and net452
2. Microsoft.NetCore.App is specific to netcoreapp1.0:

  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.0-*",
          "type": "platform"
        }
      },
      "imports": [
        "portable-net45+wp80+win8+wpa81+dnxcore50",
        "portable-net451+win8"
      ]
    },
    "net46": {}
  },

1. If I did not separate Microsoft.NETCore.App - the error I get does not tell me that Microsoft.NETCore.App is causing the problem so the experience is bad.

[TheRealPiotrP]

@eerhardt can you please take a look and understand why this is failing for net46?

[eerhardt]

It looks like the project.lock.json file is incorrect:

      "System.Diagnostics.FileVersionInfo/4.0.0-rc2-24027": {
        "type": "package",
        "frameworkAssemblies": [
          "System",
          "mscorlib"
        ],
        "compile": {
          "ref/net46/_._": {}
        },
        "runtime": {
          "lib/net46/System.Diagnostics.FileVersionInfo.dll": {}
        },

Notice the compile value of "ref/net46/_._": {}. But when I look at the package for System.Diagnostics.FileVersionInfo in my nuget package cache %userProfile%\.nuget\packages\System.Diagnostics.FileVersionInfo\4.0.0-rc2-24027\ref\net46 there is an actual assembly there: System.Diagnostics.FileVersionInfo.dll.

Looking through the CLI code, if it sees this _._ file as a "compile" assembly, it thinks it should find the assembly from the "Reference Assemblies" folder under C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6. But all the assemblies it is complaining about are not in the "Reference Assemblies" directory on my machine.

Who/what generates the lock file? NuGet? For some reason, it thinks this assembly should be a _._ compile file for net46 - i.e. get it from Reference Assemblies, but it doesn't exist in Reference Assemblies.

The root of this issue appears to be that the lock file is getting generated with this "compile": ref/net46/_._ line, but it shouldn't be.

@ericstj @emgarten @joelverhagen

[eerhardt]

Looking at why these assemblies are getting included, they all come from Microsoft.CodeAnalysis.Common. An interesting thing looking at that nuspec is that all the assemblies that are being complained about are all marked "exclude=Compile" in the nuspec:

      <group targetFramework=".NETStandard1.3">
        <dependency id="Microsoft.CodeAnalysis.Analyzers" version="1.1.0" />
        <dependency id="System.AppContext" version="4.1.0-rc2-24027" />
        <dependency id="System.Collections" version="4.0.11-rc2-24027" />
        <dependency id="System.Collections.Concurrent" version="4.0.12-rc2-24027" />
        <dependency id="System.Collections.Immutable" version="1.2.0-rc2-24027" />
        <dependency id="System.Console" version="4.0.0-rc2-24027" />
        <dependency id="System.Diagnostics.Debug" version="4.0.11-rc2-24027" />
        <dependency id="System.Diagnostics.FileVersionInfo" version="4.0.0-rc2-24027" exclude="Compile" />
        <dependency id="System.Diagnostics.StackTrace" version="4.0.1-rc2-24027" exclude="Compile" />
        <dependency id="System.Diagnostics.Tools" version="4.0.1-rc2-24027" />
        <dependency id="System.Dynamic.Runtime" version="4.0.11-rc2-24027" />
        <dependency id="System.Globalization" version="4.0.11-rc2-24027" />
        <dependency id="System.IO.FileSystem" version="4.0.1-rc2-24027" />
        <dependency id="System.IO.FileSystem.Primitives" version="4.0.1-rc2-24027" />
        <dependency id="System.Linq" version="4.1.0-rc2-24027" />
        <dependency id="System.Linq.Expressions" version="4.0.11-rc2-24027" />
        <dependency id="System.Reflection" version="4.1.0-rc2-24027" />
        <dependency id="System.Reflection.Metadata" version="1.3.0-rc2-24027" />
        <dependency id="System.Reflection.Primitives" version="4.0.1-rc2-24027" />
        <dependency id="System.Resources.ResourceManager" version="4.0.1-rc2-24027" />
        <dependency id="System.Runtime" version="4.1.0-rc2-24027" />
        <dependency id="System.Runtime.Extensions" version="4.1.0-rc2-24027" />
        <dependency id="System.Runtime.Handles" version="4.0.1-rc2-24027" />
        <dependency id="System.Runtime.InteropServices" version="4.1.0-rc2-24027" />
        <dependency id="System.Runtime.Numerics" version="4.0.1-rc2-24027" />
        <dependency id="System.Security.Cryptography.Algorithms" version="4.1.0-rc2-24027" />
        <dependency id="System.Security.Cryptography.Encoding" version="4.0.0-rc2-24027" />
        <dependency id="System.Security.Cryptography.X509Certificates" version="4.1.0-rc2-24027" />
        <dependency id="System.Text.Encoding" version="4.0.11-rc2-24027" />
        <dependency id="System.Text.Encoding.CodePages" version="4.0.1-rc2-24027" exclude="Compile" />
        <dependency id="System.Text.Encoding.Extensions" version="4.0.11-rc2-24027" />
        <dependency id="System.Threading" version="4.0.11-rc2-24027" exclude="Compile" />
        <dependency id="System.Threading.Tasks" version="4.0.11-rc2-24027" />
        <dependency id="System.Threading.Tasks.Parallel" version="4.0.1-rc2-24027" />
        <dependency id="System.Threading.Thread" version="4.0.0-rc2-24027" exclude="Compile" />
        <dependency id="System.Xml.ReaderWriter" version="4.0.11-rc2-24027" />
        <dependency id="System.Xml.XDocument" version="4.0.11-rc2-24027" />
        <dependency id="System.Xml.XmlDocument" version="4.0.1-rc2-24027" exclude="Compile" />
        <dependency id="System.Xml.XPath.XDocument" version="4.0.1-rc2-24027" exclude="Compile" />
      </group>

[eerhardt]

One other question I have about this is: I thought net46 supported netstandard1.3? If that's true, then why are there both net46 and netstandard1.3 folders in the NuGet package for System.Diagnostics.FileVersionInfo? Shouldn't there only be the netstandard1.3 folder? And net46 uses netstandard1.3.

/cc @ericstj

[davidfowl]

This is a bug in the CLI, the code we have to infer reference assemblies from package references based on the placeholder is just busted. I can think of a few practical rc2 ways to fix this:

• remove that logic and force consumers to manually add the facades to the framework assemblies list
• remove the logic and always add all facades
• try to figure out if there's a placeholder in the package vs exclude compile by looking at the package file list (sorta horrible)

[eerhardt]

What if we added all the files in the package file list that matched ref/<targetFramework>/*.dll? We "deduplicate" the libraries later, so even if it gets added multiple times, the right one will still get picked, right?

[eerhardt]

Another thought is - maybe this shouldn't be an error. Maybe it should be a warning, and we continue with the compile step. Only if the compiler needs the assembly, and it can't be found, will an actual error be created.

[chuchuva]

We are still experiencing this issue. It stops us from adopting ASP.NET Core. What's strange everything is working on my local machine but not on our build server. How can I troubleshoot and fix this issue?

[eerhardt]

@chuchuva - do you have the .NET 4.6 targeting pack installed on the build server? https://support.microsoft.com/en-us/kb/3045566. In order to target .NET 4.6 desktop, you will need either Visual Studio or the targeting pack for the version you are targeting installed on the machine.

[henkmollema]

I'm experiencing this error when building net45 on Travis (Mono 4.0.5 with .NET CLI 1.0.0-preview2-1-003177) with these dependencies:

    "net45": {
      "frameworkAssemblies": {
        "System.ComponentModel.DataAnnotations": "4.0.0.0",
        "System.Data": "4.0.0.0",
        "System.Xml": "4.0.0.0"
      }
    }

fail: /home/travis/build/.../project.json(20,22): error NU1001: The dependency System.Xml could not be resolved.

[amantur]

I copied a solution from one machine to another and started getting compilation issues. I was not able to run dnu command well on my machine.
I created a new project on my machine and it worked fine. Both project.json files were identical. Then I deleted project.json.lock file and VS restored packages. Everything built after that.

[moozzyk]

dnu has been dead for almost a year now...

[amantur]

Thanks, @moozzyk. I came back to Core after 8-10 months. It seems I need to go to release notes and docs etc.