Sdk: Enable cross-platform publishing

[johanste]

It looks like the ExeSuffix used by dotnet-publish is determined by the platform that the tool is currently being run on rather than the runtime you passed in to the publish operation.

[blackdwarf]

@johanste can you provide more details? I'm afraif I'm confused slightly by the title of the issue and the issue itself as you described it. :)

[johanste]

My apologies for not being clear. Also, I’m currently setting things up so I can actually step through the code to make sure that my observations jive with reality – but in the meantime, this is what I think that I’m seeing:

Microsoft.DotNet.Cli.Utils is using the platform you are currently running on:

namespace Microsoft.DotNet.Cli.Utils
{
internal static class Constants
{
public static readonly string ExeSuffix = RuntimeInformation.IsOSPlatform(OSPlatform.Windows) ? ".exe" : string.Empty;

public static readonly string HostExecutableName = "corehost" + ExeSuffix;
     …

…to determine the full path of corehost to pick up to copy to the output directory:

private static int PublishHost(ProjectContext context, string outputPath)
{
if (context.TargetFramework.IsDesktop())
{
return 0;
}
var hostPath = Path.Combine(AppContext.BaseDirectory, Constants.HostExecutableName);
if (!File.Exists(hostPath))
{
Reporter.Error.WriteLine($"Cannot find {Constants.HostExecutableName} in the dotnet directory.".Red());
return 1;
}
var outputExe = Path.Combine(outputPath, context.ProjectFile.Name + Constants.ExeSuffix);
// Copy the host
File.Copy(hostPath, outputExe, overwrite: true);
return 0;

This results in corehost.exe being copied to my publish folder as .exe regardless of targeted runtime when publishing from my windows box.

Also, when I take a second look at the code, it seems like it is picking up corehost* from the dotnet install directory as opposed from whatever came in my project’s references/restored packages, which would also be an issue as that file would also be specific to whatever OS you have on your build box (I assume ☺)

The correct hostpath should be based on the runtime parameter value passed in to publish. Furthermore, the version would presumably be based on the version of Microsoft.NETCore.ConsoleHost my project is referencing and not the version that came with the version of dotnet.exe/dotnet-publish.exe that I’m currently using to publish my project.

Best regards,
Johan Stenberg

From: Zlatko Knezevic [mailto:[email protected]]
Sent: Wednesday, November 25, 2015 8:59 AM
To: dotnet/cli [email protected]
Cc: Johan Stenberg Johan.[email protected]
Subject: Re: [cli] Enable cross-platform publishing (#317)

@johanstehttps://github.com/johanste can you provide more details? I'm afraif I'm confused slightly by the title of the issue and the issue itself as you described it. :)

—
Reply to this email directly or view it on GitHubhttps://github.com/dotnet/cli/issues/317#issuecomment-159671409.

[davidfowl]

Yea that's broken. Care to send a pull request?

[blackdwarf]

@johanste ah, I see, ok, yah, that's broken. :)

[MartinJohns]

This still seems to be broken. I tried to do a cross-platform publish from Windows to Ubuntu, but the resulting output still produces an .exe file.

Command used. dotnet publish --runtime ubuntu.14.04-x64 --output out5

dotnet-info:

.NET Command Line Tools (1.0.0-rc2-002374)

Product Information:
 Version:     1.0.0-rc2-002374
 Commit Sha:  f82da07fc4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

[guardrex]

Same result here.

"dependencies": {
    "Microsoft.AspNetCore.Diagnostics": "1.0.0-*",
    "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0-*",
    "Microsoft.Extensions.Logging.Console": "1.0.0-*",
    "Microsoft.AspNetCore.StaticFiles": "1.0.0-*",
    "Microsoft.AspNetCore.Mvc": "1.0.0-*",
    "Microsoft.AspNetCore.Server.Kestrel": "1.0.0-*",
    "NETStandard.Library": "1.5.0-*"
},
"frameworks": {
    "netcoreapp1.0": {
        "imports": [ "dnxcore50", "portable-net451+win8" ]
    }
},
"runtimes": {
    "ubuntu.14.04-x64": {}
},

dotnet publish --configuration Release --runtime ubuntu.14.04-x64

[MartinJohns]

@brthor Could we please re-open this issue? It's not fixed.

[brthor]

@MartinJohns @GuardRex
Using cross publish requires you to have the host in your package graph which means you must reference the latest Microsoft.NETCore.App.

I don't see anything here that suggests that that isn't working..

Take a look at an example app here:
https://github.com/dotnet/cli/blob/rel/1.0.0/TestAssets/CrossPublishTestProjects/StandaloneAppCrossPublish/project.json

[brthor]

The fallback behavior of dropping the exe exists only while we work on converting our own test assets, then without this reference you will see an error.

I think we can keep this closed out and the fallback removal is tracked here: dotnet/cli#2444

[brthor]

@MartinJohns are you referencing Microsoft.NETCore.App in your project.json?

[guardrex]

@brthor I wasn't, so that explains my misunderstanding. Thanks.

[EDIT] Yep! That got it ... test app only needed "Microsoft.NETCore.App": "1.0.0-*" dep for good ubuntu outputs. :+1:

[EDIT] Except @MartinJohns will know if the outputs will run on the platform. I can't test that far ... no Ubuntu here.

[MartinJohns]

This is my project.json file:

{
    "compilationOptions": {
        "preserveCompilationContext": true,
        "emitEntryPoint": true
    },
    "dependencies": {
        "Microsoft.AspNetCore.Diagnostics": "1.0.0-*",
        "Microsoft.AspNetCore.Server.Kestrel": "1.0.0-*",
        "Microsoft.AspNetCore.StaticFiles": "1.0.0-*",
        "NETStandard.Library": "1.5.0-*"
    },
    "frameworks": {
        "netcoreapp1.0": {
            "imports": [ "dnxcore50", "portable-net451+win8" ]
        }
    },
    "runtimes": {
        "ubuntu.14.04-x64": {}
    }
}

I do not reference Microsoft.NETCore.App. Why is this required? And if this is required, why is there no warning at all that it's missing? I see there is a warning in the latest release.

After referencing Microsoft.NETCore.App when I try to run the Ubuntu deployed packages I get this output:

root@localhost:~/rustyplane# COREHOST_TRACE=3 ./RustyPlane.Web
Tracing enabled
--- Invoked host main = {
./RustyPlane.Web
}
Resolved fxr [/root/rustyplane/libhostfxr.so]...
Tracing enabled
Exists /root/rustyplane/RustyPlane.dll
Checking if CoreCLR path exists=[/root/rustyplane/libcoreclr.so]
Detecting mode... CoreCLR present in own dir [/root/rustyplane] and checking if [RustyPlane.deps.json] file present=[0]
Host operating in split mode; own dir=[/root/rustyplane]
Tracing enabled
Usage: corehost [ASSEMBLY] [ARGUMENTS]
Execute the specified managed assembly with the passed in arguments

The Host's behavior can be altered using the following environment variables:
 COREHOST_TRACE          Set to affect trace levels (0 = Errors only (default), 1 = Warnings, 2 = Info, 3 = Verbose)

[brthor]

@GuardRex Np, I should've called this requirement out better in the issue.

[brthor]

@MartinJohns please share an ls of that directory (cc @schellap)

[MartinJohns]

root@localhost:~/rustyplane# ls -all
total 51836
drwxr-xr-x 3 root root   12288 Apr 15 18:14 .
drwx------ 7 root root    4096 Apr 15 18:03 ..
-rw-r--r-- 1 root root 8294560 Apr  7 21:23 libcoreclr.so
-rw-r--r-- 1 root root  673656 Apr  7 21:23 libcoreclrtraceptprovider.so
-rw-r--r-- 1 root root 1007272 Apr  7 21:23 libdbgshim.so
-rw-r--r-- 1 root root  594088 Mar 24 04:34 libhostfxr.so
-rw-r--r-- 1 root root  947662 Mar 24 04:34 libhostpolicy.so
-rw-r--r-- 1 root root 3544504 Apr  7 21:23 libmscordaccore.so
-rw-r--r-- 1 root root 2252464 Apr  7 21:23 libmscordbi.so
-rw-r--r-- 1 root root   69280 Apr  7 21:23 libsosplugin.so
-rw-r--r-- 1 root root  529208 Apr  7 21:23 libsos.so
-rw-r--r-- 1 root root  497160 Apr 14 19:48 libuv.so
-rw-r--r-- 1 root root    7168 Apr 14 20:20 Microsoft.AspNetCore.Diagnostics.Abstractions.dll
-rw-r--r-- 1 root root  199168 Apr 14 20:20 Microsoft.AspNetCore.Diagnostics.dll
-rw-r--r-- 1 root root    8704 Apr 14 19:59 Microsoft.AspNetCore.Hosting.Abstractions.dll
-rw-r--r-- 1 root root   59392 Apr 14 19:59 Microsoft.AspNetCore.Hosting.dll
-rw-r--r-- 1 root root    6144 Apr 14 19:59 Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
-rw-r--r-- 1 root root   51712 Apr 14 19:53 Microsoft.AspNetCore.Http.Abstractions.dll
-rw-r--r-- 1 root root   66048 Apr 14 19:52 Microsoft.AspNetCore.Http.dll
-rw-r--r-- 1 root root   28672 Apr 14 19:53 Microsoft.AspNetCore.Http.Extensions.dll
-rw-r--r-- 1 root root   21504 Apr 14 19:53 Microsoft.AspNetCore.Http.Features.dll
-rw-r--r-- 1 root root  234496 Apr 14 20:01 Microsoft.AspNetCore.Server.Kestrel.dll
-rw-r--r-- 1 root root   58880 Apr 14 20:17 Microsoft.AspNetCore.StaticFiles.dll
-rw-r--r-- 1 root root   50688 Apr 14 19:54 Microsoft.AspNetCore.WebUtilities.dll
-rw-r--r-- 1 root root 4202408 Mar 21 19:12 Microsoft.CodeAnalysis.CSharp.dll
-rw-r--r-- 1 root root 2024344 Mar 21 19:12 Microsoft.CodeAnalysis.dll
-rw-r--r-- 1 root root 5055920 Mar 21 19:12 Microsoft.CodeAnalysis.VisualBasic.dll
-rw-r--r-- 1 root root  446656 Apr  7 21:31 Microsoft.CSharp.dll
-rw-r--r-- 1 root root   10240 Apr 14 19:52 Microsoft.Extensions.Configuration.Abstractions.dll
-rw-r--r-- 1 root root   11264 Apr 14 19:52 Microsoft.Extensions.Configuration.CommandLine.dll
-rw-r--r-- 1 root root   15360 Apr 14 19:52 Microsoft.Extensions.Configuration.dll
-rw-r--r-- 1 root root   10752 Apr 14 19:53 Microsoft.Extensions.Configuration.EnvironmentVariables.dll
-rw-r--r-- 1 root root   10240 Apr 14 19:53 Microsoft.Extensions.Configuration.FileExtensions.dll
-rw-r--r-- 1 root root   14848 Apr 14 19:53 Microsoft.Extensions.Configuration.Json.dll
-rw-r--r-- 1 root root   26624 Apr 14 19:51 Microsoft.Extensions.DependencyInjection.Abstractions.dll
-rw-r--r-- 1 root root   28160 Apr 14 19:50 Microsoft.Extensions.DependencyInjection.dll
-rw-r--r-- 1 root root    8704 Apr 14 19:50 Microsoft.Extensions.FileProviders.Abstractions.dll
-rw-r--r-- 1 root root   16896 Apr 14 19:51 Microsoft.Extensions.FileProviders.Physical.dll
-rw-r--r-- 1 root root   32256 Apr 14 19:56 Microsoft.Extensions.Logging.Abstractions.dll
-rw-r--r-- 1 root root    9216 Apr 14 19:56 Microsoft.Extensions.Logging.dll
-rw-r--r-- 1 root root    8704 Apr 14 19:49 Microsoft.Extensions.ObjectPool.dll
-rw-r--r-- 1 root root   13312 Apr 14 19:56 Microsoft.Extensions.Options.dll
-rw-r--r-- 1 root root   13312 Apr 14 19:48 Microsoft.Extensions.PlatformAbstractions.dll
-rw-r--r-- 1 root root   17920 Apr 14 19:49 Microsoft.Extensions.Primitives.dll
-rw-r--r-- 1 root root   10240 Apr 14 19:58 Microsoft.Extensions.WebEncoders.dll
-rw-r--r-- 1 root root   54784 Apr 14 19:54 Microsoft.Net.Http.Headers.dll
-rw-r--r-- 1 root root  188120 Apr  7 21:32 Microsoft.VisualBasic.dll
-rw-r--r-- 1 root root   25320 Apr  7 21:32 Microsoft.Win32.Primitives.dll
-rw-r--r-- 1 root root   24288 Apr  7 21:32 Microsoft.Win32.Registry.dll
-rw-r--r-- 1 root root 2189816 Apr  7 21:23 mscorlib.dll
-rw-r--r-- 1 root root 9446400 Apr  7 21:23 mscorlib.ni.dll
-rw-r--r-- 1 root root  464896 Apr  3 10:15 Newtonsoft.Json.dll
drwxr-xr-x 2 root root    4096 Apr 15 18:03 refs
-rwxr-xr-x 1 root root  112436 Mar 24 04:34 RustyPlane.Web
-rw-r--r-- 1 root root  235334 Apr 15  2016 RustyPlane.Web.deps.json
-rw-r--r-- 1 root root  205824 Apr 15  2016 RustyPlane.Web.dll
-rw-r--r-- 1 root root   15872 Apr 15  2016 RustyPlane.Web.pdb
-rw-r--r-- 1 root root      28 Apr 15  2016 RustyPlane.Web.runtimeconfig.json
-rw-r--r-- 1 root root   61414 Apr  7 21:23 sosdocsunix.txt
-rw-r--r-- 1 root root   21856 Apr  7 21:32 System.AppContext.dll
-rw-r--r-- 1 root root   29016 Apr  7 21:32 System.Buffers.dll
-rw-r--r-- 1 root root   92912 Apr  7 21:32 System.Collections.Concurrent.dll
-rw-r--r-- 1 root root   97992 Apr  7 21:32 System.Collections.dll
-rw-r--r-- 1 root root  198896 Apr  7 21:32 System.Collections.Immutable.dll
-rw-r--r-- 1 root root   88472 Apr  7 21:32 System.Collections.NonGeneric.dll
-rw-r--r-- 1 root root   45464 Apr  7 21:32 System.Collections.Specialized.dll
-rw-r--r-- 1 root root   82848 Apr  7 21:32 System.ComponentModel.Annotations.dll
-rw-r--r-- 1 root root   21720 Apr  7 21:32 System.ComponentModel.dll
-rw-r--r-- 1 root root   92864 Apr  7 21:32 System.Console.dll
-rw-r--r-- 1 root root   22416 Apr  7 21:32 System.Diagnostics.Contracts.dll
-rw-r--r-- 1 root root   40832 Apr  7 21:32 System.Diagnostics.Debug.dll
-rw-r--r-- 1 root root   31152 Apr  7 21:32 System.Diagnostics.DiagnosticSource.dll
-rw-r--r-- 1 root root   28424 Mar 22 21:54 System.Diagnostics.FileVersionInfo.dll
-rw-r--r-- 1 root root   88456 Apr  7 21:32 System.Diagnostics.Process.dll
-rw-r--r-- 1 root root   22936 Apr  7 21:32 System.Diagnostics.StackTrace.dll
-rw-r--r-- 1 root root   22400 Apr  7 21:32 System.Diagnostics.Tools.dll
-rw-r--r-- 1 root root   36752 Apr  7 21:32 System.Diagnostics.Tracing.dll
-rw-r--r-- 1 root root  112864 Apr  7 21:32 System.Dynamic.Runtime.dll
-rw-r--r-- 1 root root   22424 Apr  7 21:32 System.Globalization.Calendars.dll
-rw-r--r-- 1 root root   22384 Apr  7 21:32 System.Globalization.dll
-rw-r--r-- 1 root root   30464 Apr  7 21:32 System.Globalization.Extensions.dll
-rw-r--r-- 1 root root   56944 Apr  7 21:23 System.Globalization.Native.so
-rw-r--r-- 1 root root   86744 Apr  7 21:32 System.IO.Compression.dll
-rw-r--r-- 1 root root   12930 Apr  7 21:23 System.IO.Compression.Native.so
-rw-r--r-- 1 root root   29080 Apr  7 21:32 System.IO.Compression.ZipFile.dll
-rw-r--r-- 1 root root   39232 Apr  7 21:32 System.IO.dll
-rw-r--r-- 1 root root   95088 Apr  7 21:32 System.IO.FileSystem.dll
-rw-r--r-- 1 root root   21920 Apr  7 21:32 System.IO.FileSystem.Primitives.dll
-rw-r--r-- 1 root root   52976 Apr  7 21:32 System.IO.FileSystem.Watcher.dll
-rw-r--r-- 1 root root   50928 Apr  7 21:32 System.IO.MemoryMappedFiles.dll
-rw-r--r-- 1 root root   42400 Apr  7 21:32 System.IO.UnmanagedMemoryStream.dll
-rw-r--r-- 1 root root  126792 Apr  7 21:32 System.Linq.dll
-rw-r--r-- 1 root root  461024 Apr  7 21:32 System.Linq.Expressions.dll
-rw-r--r-- 1 root root  223440 Apr  7 21:32 System.Linq.Parallel.dll
-rw-r--r-- 1 root root   69848 Apr  7 21:32 System.Linq.Queryable.dll
-rw-r--r-- 1 root root   92766 Apr  7 21:23 System.Native.a
-rw-r--r-- 1 root root   74748 Apr  7 21:23 System.Native.so
-rw-r--r-- 1 root root  271192 Apr  7 21:32 System.Net.Http.dll
-rw-r--r-- 1 root root   20142 Apr  7 21:23 System.Net.Http.Native.so
-rw-r--r-- 1 root root   68488 Apr  7 21:32 System.Net.NameResolution.dll
-rw-r--r-- 1 root root  307928 Apr  7 21:32 System.Net.Primitives.dll
-rw-r--r-- 1 root root   55144 Apr  7 21:32 System.Net.Requests.dll
-rw-r--r-- 1 root root  225128 Apr  7 21:32 System.Net.Security.dll
-rw-r--r-- 1 root root   14065 Apr  7 21:23 System.Net.Security.Native.so
-rw-r--r-- 1 root root  219848 Apr  7 21:32 System.Net.Sockets.dll
-rw-r--r-- 1 root root   39672 Apr  7 21:32 System.Net.WebHeaderCollection.dll
-rw-r--r-- 1 root root   30584 Apr  7 21:32 System.Net.WebSockets.dll
-rw-r--r-- 1 root root  157056 Apr  7 21:32 System.Numerics.Vectors.dll
-rw-r--r-- 1 root root   48848 Apr  7 21:32 System.ObjectModel.dll
-rw-r--r-- 1 root root  125288 Apr  7 21:32 System.Private.Uri.dll
-rw-r--r-- 1 root root   37792 Apr  7 21:32 System.Reflection.DispatchProxy.dll
-rw-r--r-- 1 root root   22880 Apr  7 21:32 System.Reflection.dll
-rw-r--r-- 1 root root   22392 Apr  7 21:32 System.Reflection.Emit.dll
-rw-r--r-- 1 root root   22448 Apr  7 21:32 System.Reflection.Emit.ILGeneration.dll
-rw-r--r-- 1 root root   21936 Apr  7 21:32 System.Reflection.Emit.Lightweight.dll
-rw-r--r-- 1 root root   24816 Apr  7 21:32 System.Reflection.Extensions.dll
-rw-r--r-- 1 root root  429288 Apr  7 21:32 System.Reflection.Metadata.dll
-rw-r--r-- 1 root root   22264 Apr  7 21:32 System.Reflection.Primitives.dll
-rw-r--r-- 1 root root   28576 Apr  7 21:32 System.Reflection.TypeExtensions.dll
-rw-r--r-- 1 root root   32992 Apr  7 21:32 System.Resources.Reader.dll
-rw-r--r-- 1 root root   22272 Apr  7 21:32 System.Resources.ResourceManager.dll
-rw-r--r-- 1 root root   39768 Apr  7 21:32 System.Runtime.dll
-rw-r--r-- 1 root root   73440 Apr  7 21:32 System.Runtime.Extensions.dll
-rw-r--r-- 1 root root   22904 Apr  7 21:32 System.Runtime.Handles.dll
-rw-r--r-- 1 root root   32152 Apr  7 21:32 System.Runtime.InteropServices.dll
-rw-r--r-- 1 root root   29624 Apr  7 21:32 System.Runtime.InteropServices.PInvoke.dll
-rw-r--r-- 1 root root   27112 Apr  7 21:32 System.Runtime.InteropServices.RuntimeInformation.dll
-rw-r--r-- 1 root root   21720 Apr  7 21:32 System.Runtime.Loader.dll
-rw-r--r-- 1 root root   70880 Apr  7 21:32 System.Runtime.Numerics.dll
-rw-r--r-- 1 root root   29632 Apr  7 21:32 System.Runtime.Serialization.Primitives.dll
-rw-r--r-- 1 root root   57208 Apr  7 21:32 System.Security.Claims.dll
-rw-r--r-- 1 root root   65984 Apr  7 21:32 System.Security.Cryptography.Algorithms.dll
-rw-r--r-- 1 root root   29608 Apr  7 21:32 System.Security.Cryptography.Cng.dll
-rw-r--r-- 1 root root   24328 Apr  7 21:32 System.Security.Cryptography.Csp.dll
-rw-r--r-- 1 root root   49432 Apr  7 21:32 System.Security.Cryptography.Encoding.dll
-rw-r--r-- 1 root root   96031 Apr  7 21:23 System.Security.Cryptography.Native.so
-rw-r--r-- 1 root root   50456 Apr  7 21:32 System.Security.Cryptography.OpenSsl.dll
-rw-r--r-- 1 root root   44992 Apr  7 21:32 System.Security.Cryptography.Primitives.dll
-rw-r--r-- 1 root root  161600 Apr  7 21:32 System.Security.Cryptography.X509Certificates.dll
-rw-r--r-- 1 root root   21224 Apr  7 21:32 System.Security.Principal.dll
-rw-r--r-- 1 root root   28936 Apr  7 21:32 System.Security.Principal.Windows.dll
-rw-r--r-- 1 root root  759552 Mar 22 21:55 System.Text.Encoding.CodePages.dll
-rw-r--r-- 1 root root   22384 Apr  7 21:32 System.Text.Encoding.dll
-rw-r--r-- 1 root root   22432 Apr  7 21:32 System.Text.Encoding.Extensions.dll
-rw-r--r-- 1 root root   64392 Apr  7 21:32 System.Text.Encodings.Web.dll
-rw-r--r-- 1 root root  112888 Apr  7 21:32 System.Text.RegularExpressions.dll
-rw-r--r-- 1 root root   50016 Apr  7 21:32 System.Threading.dll
-rw-r--r-- 1 root root   23280 Apr  7 21:32 System.Threading.Overlapped.dll
-rw-r--r-- 1 root root  177568 Apr  7 21:32 System.Threading.Tasks.Dataflow.dll
-rw-r--r-- 1 root root   26488 Apr  7 21:32 System.Threading.Tasks.dll
-rw-r--r-- 1 root root   24488 Apr  7 21:32 System.Threading.Tasks.Extensions.dll
-rw-r--r-- 1 root root   58112 Apr  7 21:32 System.Threading.Tasks.Parallel.dll
-rw-r--r-- 1 root root   22400 Apr  7 21:32 System.Threading.Thread.dll
-rw-r--r-- 1 root root   22416 Apr  7 21:32 System.Threading.ThreadPool.dll
-rw-r--r-- 1 root root   21880 Apr  7 21:32 System.Threading.Timer.dll
-rw-r--r-- 1 root root  600792 Apr  7 21:32 System.Xml.ReaderWriter.dll
-rw-r--r-- 1 root root  110800 Apr  7 21:32 System.Xml.XDocument.dll
-rw-r--r-- 1 root root  137080 Mar 22 21:55 System.Xml.XmlDocument.dll
-rw-r--r-- 1 root root  187232 Mar 22 21:55 System.Xml.XPath.dll
-rw-r--r-- 1 root root   36752 Mar 22 21:55 System.Xml.XPath.XDocument.dll

Note that I had to do chmod +x ./RustyPlane.Web first in order to make the file executable.

[brthor]

@MartinJohns What version of NETCore.App are you referencing? That looks like an old host there (March 24th)

[brthor]

Having a reference on Microsoft.NETCore.App is not required per se, but it makes things easier.

Really what you need is a dependency on the host package so we can find the host for the platform you are trying to publish for. The NETCore.App package makes that easier because it has a dependency on the host and NETStandard.Library.

[schellap]

@brthor, I believe the NETStandard.Library brings in an old host from the graph. We are building Microsoft.NETCore.App in the CLI repo with newer hosts, is that the issue in cross-publish host resolution from the graph? May be we should get rid of the old host from NETStandard.Library or start building that as well in the CLI repo? Is this the underlying issue?

[brthor]

@schellap I haven't seen any instances of NETStandard.Library bringing in an old host (is it named dotnet.exe?)

Old versions of Microsoft.NETCore.App I have seen bring in old hosts though and has caused issues.

i think the root of the confusion here is the fallback behavior which we need to remove asap.

[MartinJohns]

I was referencing "Microsoft.NETCore.App": "1.0.0-*", instead of your suggested version (with rc2-*). It should reference the same latest version, right?

My current NuGet config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="AspNetCI" value="https://www.myget.org/F/aspnetcidev/api/v3/index.json" />
    <add key="NuGet.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

Am I perhaps using outdated feeds?

I also removed NETStandard.Library from my projects file, but it resulted in no change.

Also, what exactly is the host package? What's the name of it, so I could reference it directly instead of Microsoft.NETCore.App? Or is the suggested way to always reference Microsoft.NETCore.App?

[brthor]

@MartinJohns It will not necessarily bring in the same package.

Try out this version: "Microsoft.NETCore.App": "1.0.0-rc2-*"

And add this to your nuget.config:
<add key="dotnet-core" value="https://dotnet.myget.org/f/dotnet-core" />

I looked up the host package (remembering all of these names is hard :smile:)
and it's id/version is "Microsoft.NETCore.DotNetHostPolicy" : "1.0.1-rc2-002394-00"

You could reference this directly but the suggested way is to always reference Microsoft.NETCore.App. The time when you might want to reference directly is if you didn't want the entirety of the corefx framework in your publish output, so you could pick and choose individual assemblies by not referencing NETStandard.Library.

[MartinJohns]

I tried 1.0.0-rc2-* too, but it said Lock file has not changed. - so I assume it was referencing the same package.

After adding your NuGet feed I ended up with 105 new installed packages. When trying to run the newly deployed version I get A LOT of output, more than I should probably paste here. It ends with this error:

-- Listing probe configurations...
-- Starting CoreCLR Probe from app deps.json
Deps has no coreclr entry.
Probing for CoreCLR in deps directory=[/root/out26]
Checking if CoreCLR path exists=[/root/out26/libcoreclr.so]
Checking if CoreCLR path exists=[/usr/share/dotnet/runtime/coreclr/libcoreclr.so]
Checking if CoreCLR path exists=[/usr/local/share/dotnet/runtime/coreclr/libcoreclr.so]

There is no libcoreclr.so file present in my published package.

This was while using version 1.0.0-*. Using version 1.0.0-rc2-* (and removing NETStandard.Library just in case) resulted in a working application. :tada:

So the dotnet-core feed is newer than the aspnetcidev feed? What's the suggested feeds we should use in our NuGet configuration to stay on the latest bits for rc2?

[MartinJohns]

Also, perhaps this warning should actually be an error:

publish: warning: host executable not available in dependencies, using host for current platform

It surely is not intentional to get a .exe (due to the fallback) when I clearly specified that I want an Ubuntu version.

[brthor]

@MartinJohns That will be an error after dotnet/cli#2444 is resolved, but that is blocked on the work I am doing here: dotnet/cli#2438 It's just a Point in time issue.

All of the latest .NET core packages including NETStandard.Library and Microsoft.NETCore.App are published to the dotnet-core feed first, so if you want the bleeding edge that's the feed to go to.

Are you content to close this out since you made a working application?

[MartinJohns]

Yes, I think this can be closed again. Thanks for the replies. :+1:

[andriysavin]

When I try to publish a self-contained app for win10-arm using RC2 (according to instructions here) I get the same warning: host executable not available in dependencies, using host for current platform. And in the output I get x64 executable (what's the sense in such fallback?). From this thread I still don't see how to make this working correctly.

[guardrex]

@andriysavin Looks like this is still being worked on https://github.com/dotnet/cli/issues/2949 and https://github.com/dotnet/cli/issues/2343.

[andriysavin]

@GuardRex Ok, its hard to see clearly what's the status of the bug, since there are many similar issues which are somehow related, some of which are open, some closed (like this)...

[brthor]

@andriysavin We left the fallback in place simply not to break existing applications.

If you wanted to get this working on ARM you'd have to perform a build of native host of the CLI, on that platform, and restore your application against the locally built packages which would exist in artifacts/$Rid/corehost and artifacts/$Rid/corehostDummyPackages after a successful build.

The issue is that the CLI does not currently build for arm, so there is no native host published for that platform.

I believe it would be doable, but don't know what challenges lie on that road.

[andriysavin]

@brthor Its still not clear why can't the ARM packages be built on a different platform, and why CLI doesn't support ARM while there is a runtime for ARM (like win10-arm) and I can build the native host for ARM myself. I'm also wondering will ARM support ever be available out of the box, or will it always be a DIY task for enthusiasts? When went to the .Net Core installation downloads page, I was surprised (or not) that even for the .Net Core without the SDK there weren't binaries for ARM.

[blackdwarf]

@andriysavin for now, we have a roadmap and a supported OS matrix that you can see in the repo. We are working off of that for RTM and ARM support for the CLI is not planned at this time.

Of course, this may change in the future as we hear feedback from the users on theirs needs and as we broaden support for the CLI tooms.

[shootdaj]

@blackdwarf If ARM support for CLI is not planned, how are we supposed to publish applications to win10-arm? Seems like you cannot publish for win10-arm using a regular x64 machine, and since you don't plan on adding support for arm to CLI, I don't see how we can accomplish running .NET programs on arm machines like Raspberry Pi, which was a fundamental feature of .NET Core.

[bogdandanielb]

Any solution to "host executable not available in dependencies, using host for current platform" ?
I've tried with older versions of DNX for ARM but they are missing coreclr.dll.

[morrisonbrett]

I'm waiting for this as well. I have a Windows IoT Core project for Raspberry Pi 3 that is blocked until --runtime "win10-arm"publishing is supported in .NET Core.

[bogdandanielb]

@morrisonbrett Did you try with older DNX CLI and RC1 ?

[morrisonbrett]

I refuse to go backwards and spend the time getting it all right, and then when RC3 or RTM comes out hopefully with ARM support then have to go forwards again. I will wait.

This guy gave a presentation in Los Angeles this week. He ended up having to go back to -beta7 to get it to work.

http://www.meetup.com/LADOTNET/events/231446276/?comment_table_id=245593091

[shootdaj]

I am ^^^ that guy who gave the presentation. I tried the older DNX CLI and RC1. Didn't work either. The problem is twofold. You cannot cross publish from x86/x64 to ARM, and CLI is not runnable/buildable on ARM. Given these two restrictions, I don't see a way to run an RC1/RC2 application on an ARM machine like Raspberry Pi. I tried a few other versions in between beta7, RC1, and RC2, and none of them worked. I also tried those with various versions of the CLI and DNX/DNVM. After spending almost an entire day on it, I gave up. I'll come back to it once cross-publishing is supported. Like @morrisonbrett said, it's a lot of work trying to figure out which combinations will work. And after trying out all possible combinations I could, I found that none of them worked.

[guardrex]

@DamianEdwards @shanselman Good feedback here from @shootdaj regarding getting .NET Core on the RPi.

[shahid-pk]

@shootdaj i think @myungjoo with his team was somewhat successful in building a cli version for arm/linux.
I hope @myungjoo could shed some light on what is the current status or constraints for it to happen from community contributions at least on linux.

although the issue is more for cross publishing and support for win10 iot i guess but still will be helpful for the community here to know where does arm/linux stands right now.

[shootdaj]

I just now read the issue that was linked to this thread: https://github.com/aspnet/dnx/issues/3358

@KoalaBear84 was able to get it to work with RC2. Apparently you have to manually copy the coreclr.dll and possibly also libuv.dll into the published folder (in the appropriate subfolder) before copying it to the Pi. Gonna try it this weekend and see if that goes anywhere.

[bogdandanielb]

@shootdaj You have to copy all the missing files not just coreclr.dll. Please check my comment https://github.com/aspnet/dnx/issues/3358#issuecomment-225340582

[capcata]

Any updates about .Net Core for ARM?
Thanks.