dotnet build puts wrong native executable/libraries into runtime specific output
See original GitHub issueSteps to reproduce
On OS X 10.11.4 (not tested on other OSes):
- Create a standalone app targeting
net451
andnetcoreapp1.0
forwin7-x64
andosx.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
Issue Analytics
- State:
- Created 7 years ago
- Comments:15 (15 by maintainers)
Top GitHub 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.
Good … at least its a stable bug …