Nuget doesn't seem to download project dependencies in Linux

[DemianTinkiel]

NuGet product used NuGet.exe | dotnet.exe
NuGet version (x.x.x.xxx): 4.8.2.5835
dotnet.exe --version (if appropriate): 2.2.203
OS version (i.e. win10 v1607 (14393.321)): Ubuntu 18.04 LTS

Detailed repro steps so we can see the same problem

1. Define a csproj with PackageReference (s)
2. nuget restore | dotnet restore
3. msbuild fails - dependency missing
   ...

I have a project where I define a build task
as

<UsingTask TaskName="ClassLibrary1.Json2ClassTask" AssemblyFile="bin/Debug/netstandard2.0/ClassLibrary1.dll" />
    <Target Name="PostBuild" AfterTargets="PostBuildEvent">
        <ClassLibrary1.Json2ClassTask SchemasLocation="./schemas" OutputLocation="gen-csharp" />
        <Message Text="AfterBuild executed" Importance="high" />
    </Target>

and the following dependencies define in the .csproj

 <ItemGroup>
      <PackageReference Include="Microsoft.Build.Framework" Version="16.0.461" />
      <PackageReference Include="Microsoft.Build.Utilities.Core" Version="16.0.461" />
      <PackageReference Include="NJsonSchema" Version="9.14.1" />
      <PackageReference Include="NJsonSchema.CodeGeneration" Version="9.14.1" />
      <PackageReference Include="NJsonSchema.CodeGeneration.CSharp" Version="9.14.1" />
    </ItemGroup>

doing dotnet resore or nuget restore says all ok but when I do msbuild I get

/home/demiant/projects/ClassLibrary1/ClassLibrary1/ClassLibrary1.csproj(40,9): error MSB4018: The "ClassLibrary1.Json2ClassTask" task failed unexpectedly.
/home/demiant/projects/ClassLibrary1/ClassLibrary1/ClassLibrary1.csproj(40,9): error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly 'NJsonSchema.CodeGeneration.CSharp, Version=9.14.1.0, Culture=neutral, PublicKeyToken=c2f9c3bdfae56102'. The system cannot find the file specified.
/home/demiant/projects/ClassLibrary1/ClassLibrary1/ClassLibrary1.csproj(40,9): error MSB4018: 
/home/demiant/projects/ClassLibrary1/ClassLibrary1/ClassLibrary1.csproj(40,9): error MSB4018: File name: 'NJsonSchema.CodeGeneration.CSharp, Version=9.14.1.0, Culture=neutral, PublicKeyToken=c2f9c3bdfae56102'
/home/demiant/projects/ClassLibrary1/ClassLibrary1/ClassLibrary1.csproj(40,9): error MSB4018:    at ClassLibrary1.Json2ClassTask.Generate()

Mono version:

Mono JIT compiler version 5.20.1.19 (tarball Thu Apr 11 09:02:17 UTC 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug 
        Interpreter:   yes
        LLVM:          yes(600)
        Suspend:       hybrid
        GC:            sgen (concurrent by default)

[DemianTinkiel]

dotnet.log
adding logs.
Also did dotnet restore --packages .\packages --force to see if I could force download to a specific location but it produces nothing

[rrelyea]

Restore doesn’t run as part of msbuild unless you ask for it to be.

Can you try:
Msbuild /restore
Which will do a restore and then run build (/t:build is default), as two separate steps, which is ideal, because restore can change how build works.

[DemianTinkiel]

Hi @rrelyea thanks for the answer. I tried msbuild /restore and gives me the same behavior: restore task says ok, build fails on missing assembly for dependency

[DemianTinkiel]

Could this be something related to #7956, i.e incompatibility between mono & sdk?

[to-marss]

Team,
Any updates on this please? PackageReferences included in .wapproj (MSIX Project) doesn't seem to work in Linux pipeline due to this. it is unable to restore <PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.22621.1" PrivateAssets="all" /> therefore build fails. Any help is much appreciated.

[zivkan]

A sample solution, that we can unzip and try for ourselves, would make it much easier for us to investigate. Customers using the .NET SDK on Linux is not uncommon, especially with the popularity of Docker, and most customers are not reporting problems, so some effort is needed to isolate the problem.

Your comment about wapproj is helpful, though we'd still need to figure out how to create one of those project files, then test it works on Windows before we can test on Linux. If you could provide us with a zip, then that reduces the friction to investigate.

[to-marss]

A sample solution, that we can unzip and try for ourselves, would make it much easier for us to investigate. Customers using the .NET SDK on Linux is not uncommon, especially with the popularity of Docker, and most customers are not reporting problems, so some effort is needed to isolate the problem.

Your comment about wapproj is helpful, though we'd still need to figure out how to create one of those project files, then test it works on Windows before we can test on Linux. If you could provide us with a zip, then that reduces the friction to investigate.

@zivkan Thanks for the prompt reply. I think I misunderstood few things there. It's not the package restore fails in Linux build. In the MSIX.wapproj seems dotnet build fails to restore since this packaging is done via MSBUILD. Hence, the build fails with restore when the solution is run with dotnet build. Related to this.