Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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:

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

git clone
cd cli-build-artifact-issue-repro
git checkout initial-state
./ > 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


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






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/TestApp <-- executable
… (json-files)

bin/Release/netcoreapp1.0/osx.10.11-x64/publish/TestApp <-- executable
… (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/TestApp <-- bug?: OS X executable for Windows runtime
… (json-files)

bin/Release/netcoreapp1.0/win7-x64/publish/TestApp.exe <-- fine: Windows executable
bin/Release/netcoreapp1.0/win7-x64/publish/hostfxr.dll <-- fine: Windows libraries
… (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:closed
  • Created 7 years ago
  • Comments:15 (15 by maintainers)

github_iconTop GitHub Comments

TheRealPiotrPcommented, May 8, 2016

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.

guardrexcommented, May 8, 2016

Good … at least its a stable bug …


Read more comments on GitHub >

github_iconTop Results From Across the Web

dotnet build puts wrong native executable/libraries into ...
The publish output is correct, containing Windows executable / runtime. bin/Release/netcoreapp1.0/osx.10.11-x64/libhostfxr.dylib bin/Release/ ...
Read more >
NET Core project with native library dependency
I have tried to use MSBuild targets solution here, but this only copies one dll to the main output folder at compile time....
Read more >
Native AOT deployment overview - .NET
Native AOT apps can run in restricted environments where a JIT isn't allowed. Native AOT applications target a specific runtime environment, ...
Read more >
Building a Native Executable
Mandrel's main goal is to provide a way to build native executables specifically designed to support Quarkus. Mandrel releases are built from a...
Read more >
Making a tiny .NET Core 3.0 entirely self-contained single ...
NET Core 3.0 SDK's now-built-in Tree Trimmer creates a 13 meg single executable that includes everything it needs to run. C:\Users\scott\Desktop ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found