dotnet build with runtime specified does not create the right output

[TheRealPiotrP]

Moved from https://github.com/dotnet/cli/issues/5039 on behalf of @Fabi, @nguerrera

---

Steps to reproduce

1. Install Visual Studio 2017 RC
2. Follow the "Deploying a simple self-contained deployment" part from https://docs.microsoft.com/en-us/dotnet/articles/core/preview3/deploying/ until step 5

Expected behavior

After running the dotnet build -r win10-x64 command a folder with the build files (including an .exe file not only dll) should be created at ".\bin\Debug\netcoreapp1.0<runtime_identifier>"

Actual behavior

There is no runtime folder with executables generated. That only works with the publish command now.
Before on json based project files it worked fine.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview4-004233)

Product Information:
 Version:            1.0.0-preview4-004233
 Commit SHA-1 hash:  8cec61c6f7

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

---

@nguerrera this is the standalone publish scenario. It should work like this:

on build

Build produces the portable output as well as a RID-specific output. The RID-specific output contains the portable output + the appropriate RID-specific host for the app. That host still uses deps.json, etc. to load Shared Framework artifacts from the nuget cache

on publish

The publish output is RID specific. It includes everything from the RID-specific build output + everything from the RID-specific Shared Framework. The publish output can now be zip'd and then deployed to any host with a matching RID.

[vad710]

Just to clarify - is the platform-specific binaries not getting generated at all or is it getting generated in the wrong folder?

[Fabi]

They are not generated at all on build. I searched them but never found them, so I guess they are not generated.

[nguerrera]

@piotrpMSFT @eerhardt @livarcocc I cannot reproduce this with project.json. My steps are below. What am I missing?

• Check version

C:\temp\pj>dotnet --version
1.0.0-preview2-003131

• Create project

C:\temp\pj>mkdir a

C:\temp\pj>cd a

C:\temp\pj\a>dotnet new
Created new C# project in C:\temp\pj\a.

• Add runtimes to project

C:\temp\pj\a>notepad project.json

C:\temp\pj\a>type project.json
{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable",
    "emitEntryPoint": true
  },
  "dependencies": {},
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "type": "platform",
          "version": "1.0.1"
        }
      },
      "imports": "dnxcore50"
    }
  },
  "runtimes": {
    "win7-x86": {}
  }
}

• restore

C:\temp\pj\a>dotnet restore
log  : Restoring packages for C:\temp\pj\a\project.json...
log  : Writing lock file to disk. Path: C:\temp\pj\a\project.lock.json
log  : C:\temp\pj\a\project.json
log  : Restore completed in 1267ms.

• build

C:\temp\pj\a>dotnet build -r win7-x86
Project a (.NETCoreApp,Version=v1.0) will be compiled because expected outputs are missing
Compiling a for .NETCoreApp,Version=v1.0

Compilation succeeded.
    0 Warning(s)
    0 Error(s)

Time elapsed 00:00:00.8792247

• Check what's output:

C:\temp\pj\a>dir /s /b bin
C:\temp\pj\a\bin\Debug
C:\temp\pj\a\bin\Debug\netcoreapp1.0
C:\temp\pj\a\bin\Debug\netcoreapp1.0\a.deps.json
C:\temp\pj\a\bin\Debug\netcoreapp1.0\a.dll
C:\temp\pj\a\bin\Debug\netcoreapp1.0\a.pdb
C:\temp\pj\a\bin\Debug\netcoreapp1.0\a.runtimeconfig.dev.json
C:\temp\pj\a\bin\Debug\netcoreapp1.0\a.runtimeconfig.json

[nguerrera]

Nevermind, my problem was that I still had type: "platform" on the Microsoft.NETCore.App ref. Now I see the old behavior described. Thanks to @eerhardt for helping me offline. He also has some reservations about replicating this in msbuild. I'll let him comment on that.

[vad710]

I just wanted to follow up - is there a work-around to this issue (not being able to cross compile into Mac/Linux) or do we just have to wait for this to be fixed and released?

[eerhardt]

Note that when fixing this, we need to ensure dotnet run works for projects like:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeFrameworkVersion>2.0.0-beta-001482-00</RuntimeFrameworkVersion>
    <RuntimeIdentifier>win7-x64</RuntimeIdentifier>
  </PropertyGroup>
</Project>

To enable this, I think the things that need to be done are:

1. Copy the hostfxr and hostpolicy assemblies to the output folder
2. Copy the dotnet executable to the output folder and rename it to $(TargetName)[.exe]
   • We also need to change the "Run Information" to point to this executable instead of the dotnet on the path.
3. Set the output folder to have the RID in it.
   • This is how project.json based projects did it.

See https://github.com/dotnet/cli/blob/rel/1.0.0-preview2.1/src/Microsoft.DotNet.Compiler.Common/Executable.cs#L96-L108 for how this worked on project.json based projects. Specifically the CoreHost.CopyTo(_runtimeOutputPath, _compilerOptions.OutputName + Constants.ExeSuffix); part, which does the first two steps above.

[eerhardt]

@vad710 - no workaround for dotnet build yet. I'm working on the fix now.

You can use dotnet publish to cross compile into Mac/Linux, which works today.

[vad710]

@eerhardt - I tried doing a dotnet publish today and I saw the same behavior as #696

[nguerrera]

@vad710 At least currently, you'll need to pass the -r used for publish to restore as well.

[vad710]

I used the -r parameter in the above publish command

[nguerrera]

Also pass it to restore:

dotnet restore -r [rid]
dontnet publish -r [rid]

[Fabi]

You're sure it's working?

I just tried different versions of the .net cli and swapped the sdk files with the master repo files, but I still don't get the output

[nguerrera]

@Fabi are you on Mac OS X? @eerhardt Could this be #834 ?

[Fabi]

Nope, I'm on Windows 10. The dotnet publish command still creates a runnable output, but the dotnet build command not with a set rid (at least for me)

[Fabi]

OK, I just installed the latest cli tools again and it seem to generate an exe with dotnet build -r win10-x64, but it should be in a win10-x64 subfolder I think:

[nguerrera]

We decided not to change the default output folder this late in the cycle. You can set AppendRuntimeIdentifierToOutputputPath=true to opt in to that behavior.