Publishing from Windows to Linux no longer working after upgrading to VS2017 / csproj

Steps to reproduce

I have a website powered by ASP.NET Core 1.1.1: https://github.com/Daniel15/Website. I’m trying to upgrade from VS2015 to VS2017. To publish the site, I’m running a command like this:

dotnet publish . -o "c:\TempPublish\site" -c Release -r debian-x64

And then rsyncing the directory to my Linux server. I specify the target runtime as debian-x64 to avoid Windows-specific binaries in the output dir (eg. libuv.so instead of libuv.dll)

Expected behavior

Build works. This works fine with the old project.json format.

Actual behavior

When I try it with the converted csproj I get:

C:\Program Files\dotnet\sdk\1.0.0\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(92,5): error : Assets file ‘C:\src\dan.cx\Daniel15.Web\obj\project.assets.json’ doesn’t have a target for ‘.NETFramework,Version=v4.5.2/debian-x64’. Ensure you have restored this project for TargetFramework=‘net452’ and RuntimeIdentifier=‘debian-x64’. [C:\src\dan.cx\Daniel15.Web\Daniel15.Web.csproj]

When I remove -r debian-x64 from the publish command, the resulting built site doesn’t actually run on Mono any more - I get Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.. It looks like it’s copying a Windows build of System.Runtime.InteropServices.RuntimeInformation rather than a Linux build, at least judging by the paths in the PDBs (D:\A\_work\39\s\bin\obj\Windows_NT.AnyCPU.Release\... vs D:\A\_work\39\s\bin\obj\Unix.AnyCPU.Release...).

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0)

Product Information:
 Version:            1.0.0
 Commit SHA-1 hash:  e53429feb4

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

[Daniel15]

I’m the person that opened https://github.com/aspnet/MvcPrecompilation/issues/102, I forgot to close this issue. Let’s track it there 😃

[pranavkm]

I think there’s a couple issues around the tool failing in the precompilation repo:

• https://github.com/aspnet/MvcPrecompilation/issues/72
• https://github.com/aspnet/MvcPrecompilation/issues/102

We can use these to track the issue.