sdk: dotnet build puts wrong native executable/libraries into runtime specific output

Steps to reproduce

On OS X 10.11.4 (not tested on other OSes):

Create a standalone app targeting net451 and netcoreapp1.0 for win7-x64 and osx.10.11-x64 runtimes.
Add a native dependency for reference (e.g. Libuv).
Build and Publish for all runtimes and frameworks (Release or Debug).

Repository with a repro is available here: https://github.com/dasMulli/cli-build-artifact-issue-repro

The master branch contains the complete build output as well as the used CLI build. To reproduce:

git clone https://github.com/dasMulli/cli-build-artifact-issue-repro.git
cd cli-build-artifact-issue-repro
git checkout initial-state
./repro.sh > repro.log

Expected behavior

Each runtime-specific directory should contain only native components and executables for the corresponding runtime. OR Each runtime-specific directory should only contain native components and executables for the host runtime (osx.10.11-x64 in this case). (this may make sense to run mono TestApp.exe and having *.dylib files)

Actual behavior

net451

The output for net451 is fine. When dotnet publish is run, build and publish output matches.

bin/Release/net451/osx.10.11-x64/libuv.dylib
bin/Release/net451/osx.10.11-x64/TestApp.exe
bin/Release/net451/osx.10.11-x64/TestApp.pdb

bin/Release/net451/osx.10.11-x64/publish/libuv.dylib
bin/Release/net451/osx.10.11-x64/publish/TestApp.exe
bin/Release/net451/osx.10.11-x64/publish/TestApp.pdb

bin/Release/net451/win7-x64/libuv.dll
bin/Release/net451/win7-x64/TestApp.exe
bin/Release/net451/win7-x64/TestApp.pdb

bin/Release/net451/win7-x64/publish/libuv.dll
bin/Release/net451/win7-x64/publish/TestApp.exe
bin/Release/net451/win7-x64/publish/TestApp.pdb

netcoreapp1.0

The output for netcoreapp1.0 is different: For the win7-x64 build output, an OS X executable and OS X libraries are dropped. The publish output is correct, containing Windows executable / runtime.

bin/Release/netcoreapp1.0/osx.10.11-x64/libhostfxr.dylib
bin/Release/netcoreapp1.0/osx.10.11-x64/libhostpolicy.dylib
bin/Release/netcoreapp1.0/osx.10.11-x64/TestApp <-- executable
bin/Release/netcoreapp1.0/osx.10.11-x64/TestApp.dll
bin/Release/netcoreapp1.0/osx.10.11-x64/TestApp.pdb
… (json-files)

bin/Release/netcoreapp1.0/osx.10.11-x64/publish/TestApp <-- executable
bin/Release/netcoreapp1.0/osx.10.11-x64/publish/TestApp.deps.json
bin/Release/netcoreapp1.0/osx.10.11-x64/publish/TestApp.dll
bin/Release/netcoreapp1.0/osx.10.11-x64/publish/TestApp.pdb
bin/Release/netcoreapp1.0/osx.10.11-x64/publish/libuv.dylib
… (more dylib-files, runtime, dependencies)

bin/Release/netcoreapp1.0/win7-x64/libhostfxr.dylib <-- bug?: OS X dylibs for Windows runtime
bin/Release/netcoreapp1.0/win7-x64/libhostpolicy.dylib
bin/Release/netcoreapp1.0/win7-x64/TestApp <-- bug?: OS X executable for Windows runtime
bin/Release/netcoreapp1.0/win7-x64/TestApp.dll
bin/Release/netcoreapp1.0/win7-x64/TestApp.pdb
… (json-files)

bin/Release/netcoreapp1.0/win7-x64/publish/TestApp.dll
bin/Release/netcoreapp1.0/win7-x64/publish/TestApp.exe <-- fine: Windows executable
bin/Release/netcoreapp1.0/win7-x64/publish/hostfxr.dll <-- fine: Windows libraries
bin/Release/netcoreapp1.0/win7-x64/publish/hostpolicy.dll
bin/Release/netcoreapp1.0/win7-x64/publish/libuv.dll
… (more dll-files, runtime, dependencies)

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview1-preview1-002697)

Product Information:
 Version:     1.0.0-preview1-preview1-002697
 Commit Sha:  08b3ad9e88

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.11
 OS Platform: Darwin
 RID:         osx.10.11-x64

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 15 (15 by maintainers)

Most upvoted comments

This issue is essentially a dupe of dotnet/sdk#5631, though I appreciate the thorough investigation and want to be sure @krwq confirms this full scenario is covered before he closes this as a duplicate.

We haven’t fixed this yet because the issue is a bit tightly tied to tooling experiences which we don’t want to destabilize before getting the next named release locked down. Before cross-publish and cross-build were options, CLI would copy its own host binaries into the build output to facilitate running without publishing. We already enabled cross-publish, which was a new feature and therefore moved to the correct long-term behavior of getting the host out of its resolved nuget package. However, for Build we did not replace the behavior to facilitate short-term stability. This will come soon after we branch.

TheRealPiotrP on May 8, 2016

Good … at least its a stable bug …

capture

guardrex on May 8, 2016

oooops!

[EDIT] So much for “good outputs” 😄 I’m going back to the actual test self-contained proj now to repro this there, since the project.json in that one is a bit different.

capture

guardrex on May 8, 2016