在fx_muxer.cpp上获得主张:316在ubuntu上的.NET Core App 1.0启动时

Question

我在添加了针对netstandard1.3的PCL依赖性之后，在Ubuntu上看到了我的.NET Core App 1.0的以下输出。

foo: /opt/code/src/corehost/cli/fxr/fx_muxer.cpp:316: static pal::string_t fx_muxer_t::resolve_fx_dir(host_mode_t, const pal::string_t &, const runtime_config_t &, const pal::string_t &): Assertion `mode != host_mode_t::standalone' failed.
Aborted (core dumped)

那行代码是：

// No FX resolution for standalone apps.
assert(mode != host_mode_t::standalone);

这以前没有发生在我身上，所以我不确定从哪里开始寻找。该host_mode_t在启动时如何解决？

在我看来，问题是由于配置文件中存在错误吗？

预先感谢。

编辑：

一旦我设置COREHOST_TRACE=1：

，这是启动时应用程序的完整输出

Tracing enabled
--- Invoked dotnet [version: 1.1.0, commit hash: 0bc55b1fcc0bd58987bf96683c15596918db2b13] main = { ./foo --staging }
Resolved fxr [/var/www/html/foo/staging/libhostfxr.so]...
Tracing enabled
--- Invoked hostfxr [commit hash: 928f77c4bc3f49d892459992fb6e1d5542cb5e86] main Own DLL
ath=[/var/www/html/foo/staging/foo.dll]
Checking if CoreCLR path exists=[/var/www/html/foo/staging/libcoreclr.so]
Detecting mode...
CoreCLR present in own dir [/var/www/html/foo/staging] and checking if [foo.deps.json] file present=[1]
--- Executing in standalone mode...
Treating application '/var/www/html/foo/staging/foo.dll' as a managed executable.
App runtimeconfig.json from [/var/www/html/foo/staging/foo.dll]
Runtime config is cfg=/var/www/html/foo/staging/foo.runtimeconfig.json
dev=/var/www/html/foo/staging/foo.runtimeconfig.dev.json
Attempting to ead runtime config: /var/www/html/foo/staging/foo.runtimeconfig.json
Attempting to read dev runtime config: /var/www/html/foo/staging/foo.runtimeconfig.dev.json
Runtime config[/var/www/html/foo/staging/foo.runtimeconfig.json] is valid=[1]
foo: /opt/code/src/corehost/cli/fxr/fx_muxer.cpp:316: static pal::string_t fx_muxer_t::resolve_fx_dir(host_mode_t, const pal::string_t &, const runtime_config_t &, const pal::string_t &): Assertion `mode != host_mode_t::standalone' failed. Aborted (core dumped)

Answer 1

这个问题是双重的：

1. 我正在使用rsync将应用程序发布到我的服务器，但是我不再使用使用文件，因此依赖性配置文件仍然存在;
2. 在某个时候，我在" NetCoreApp1.0"目标的依赖项中添加了" Microsoft.netcore.app"的" type"。这导致生成DLL，而不是独立的可执行文件。