Core: How to run published console app?

[ryanelian]

Let's say I have a hello world application named helloworld.

I ran dotnet restore then dotnet publish. This appears:

Publishing helloworld for .NETCoreApp,Version=v1.0
Project helloworld (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
publish: Published to C:\Ryan\helloworld\bin\Debug\netcoreapp1.0\publish
Published 1/1 projects successfully

In the folder I have:

helloworld.deps.json
helloworld.dll
helloworld.pdb
helloworld.runtimeconfig.json

Looks compiled to me but doesn't seem to be an exe file.

How to run this? Or is there a special compilation flag that outputs executable?

Thanks in advance!

[oaiey]

dotnet run path/to/helloworld.dll

Your published project looks like a portable application which does not have a native bootstrapper like a shell script or a executable.

[ryanelian]

Heya. Thanks for responding but that doesn't seem to be working.

Yeah I'm curious about that too. I wonder if there's a way to generate the console app as executable.

[Petermarcu]

You can also run dotnet . A portable app can run on any os and depends on the shared framework for the target platform being there. Currently, the way to get an executable app is to standalone and specify the target runtime ID in project.json. Remove, type: Platform from the netcore.app package reference and add a runtimes section with the right values such as win7-x64.

[ryanelian]

Oh wow that worked. Thanks Peter! Managed to spit out the executable by using this project.json (for those who are wondering as well):

{
  "version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": true
  },
  "dependencies": {
    "Microsoft.NETCore.App": {
      //"type": "platform",
      "version": "1.0.0-rc2-3002702"
    }
  },
  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  },
  "runtimes":{
    "win10-x64": { }
  }
}

Managed to dig out abit about project.json here.

You can also run dotnet

Any idea how to do that against the previously compiled helloworld.dll using the command line? I'm still curious about this one.

Also, since the .NET Core is cross-platform, can I run that helloworld.dll compiled on Windows on
Linux or Mac?

---

EDIT

Slightly off-topic but after reading around I tried playing around and used this configuration:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": true
  },
  "dependencies": {
    "NETStandard.Library": {
      "type": "platform",
      "version": "1.5.0-rc3-24116-00"
      //https://dotnet.myget.org/feed/dotnet-core/package/nuget/NETStandard.Library
    }
  },
  "frameworks": {
    "netstandard1.5": { }
  }
}

Then I do dotnet run. This appears:

E:\helloworld>dotnet run
Project helloworld (.NETStandard,Version=v1.5) will be compiled because inputs were modified
Compiling helloworld for .NETStandard,Version=v1.5

Compilation succeeded.
    0 Warning(s)
    0 Error(s)

Time elapsed 00:00:01.7820775


The targeted framework { 'NETStandard.Library': '1.5.0-rc3-24116-00' } was not found.
  - Check application dependencies and target a framework version installed at:
      C:\Program Files\dotnet\shared\NETStandard.Library
  - Alternatively, install the framework version '1.5.0-rc3-24116-00'.

No error but it asks me to install a framework. How to do this?

[aL3891]

You mean convert a previously compiled portable app into a standalone one? I don't think that's possible, at least not with the current version of the tooling

[ryanelian]

You mean convert a previously compiled portable app into a standalone one? I don't think that's possible, at least not with the current version of the tooling

Nonono, I meant running the .dll itself. I can't seem to run the compiled binary with dotnet (the command line simply says Object reference not set to an instance of an object. (See screenshot)

[aL3891]

I see, that should work.. if the app is compiled as portable it should run anywhere dotnet is installed. (shouldn't net a null reference error anyway) i'd file a bug on the cli repo

Regarding you edit, did you mean to run on the rc3 bits?

[ryanelian]

Regarding the edit, yes I meant to run on RC3 bits. Just pure curiosity. Do you know how to do it?

[aL3891]

ok :)
You need to add the right myget feeds to nuget.config so for example:

<configuration>
  <packageSources>
    <add key="coreFx" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
    <add key="NuGet" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

or you can just add it in the vs options

Here is a sample project.json for a console app:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": true
  },

  "dependencies": {
    "Microsoft.NETCore.App": {
      "version": "1.0.0-rc3-*"
    },
    "System.Runtime.CompilerServices.Unsafe": "4.0.0-rc3-*"
  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  },

"runtimes": {
    "win10-x64": { }
  }
}

[gulshan]

To run a published dll-
dotnet app.dll
Don't use "dotnet run".

[ryanelian]

To run a published dll-
dotnet app.dll
Don't use "dotnet run".

Oh wow. That's unexpected. Maybe someone ought to make that clearer in the docs. Thanks!

[jkristia]

@ryanelian, agree - it would be good if it was mentioned right in 'dotnet --help'. I spend a bit of time this morning Bing'ing how to get my console app running on OSX from the publish folder

[mairaw]

@ryanelian and @jkristia, I've created the following issue on the core-docs repo to improve discoverability of this information:
https://github.com/dotnet/core-docs/issues/473

[mattcdavis1]

can someone point me to where i can get a list of all the options for runtimes? I'm trying to publish an executable for mac os but i'm not sure what i should be putting as a value in the runtimes json field. Right now when i run publish i'm just getting a folder with the same files listed in the first comment.

[svick]

@mattcdavis1 See Runtime Identifier catalog in the documentation.

[mattcdavis1]

@svick - thanks! based on that article - i've created a json file that looks like this. However when i run dotnet publish i'm still not seeing a mac executable file. Am i missing something (right now the app is just a "Hello World" single line app)?

[svick]

@mattcdavis1 Based on this article, you also need to remove the "type": "platform" line from your project.json.

[mattcdavis1]

yep - that worked. thanks!

[bitslasher]

First off, I'd like to say thank you to you guys for all this information. It really helped me out. Secondly, however, after reading this, I felt really sad in the pit of my stomach that this is so convoluted. This seems like a real mess. It feels like we've went backwards somehow.

[davidfowl]

It's not very clean. We're looking at moving to a model where you always develop portable apps but you can choose to deploy standalone at publish time.

[tbird321]

This did not work for centos linux just for windows mac

[vad710]

I am not sure if it's appropriate for me to add to this thread, but with the obsoletion of project.json and using the new msbuild tools as part of Visual Studio 2017 RC - what is the process of specifying the runtimes in the csproj file?

[albertromkes]

I tried it with the following snippet:

<PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp1.1</TargetFramework> <RuntimeIdentifier>win10-arm64</RuntimeIdentifier> <RuntimeIdentifier>win10-x64</RuntimeIdentifier> <RuntimeIdentifier>debian.8-x64</RuntimeIdentifier> </PropertyGroup>
It does publish succesfully: dotnet publish -r debian.8-x64

[Petermarcu]

You can also specify them with a single RuntimeIdentifier element:

<PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp1.1</TargetFramework> <RuntimeIdentifier>win10-arm64;win10-x64;debian.8-x64</RuntimeIdentifier> </PropertyGroup>

As @davidfowl mentioned, we're looking into some alternate models that don't require changing your project in order to publish a standalone app or for a specific runtime.

[vad710]

@albertromkes - were you able to actually generate the proper build for debian? According to this other bug, there is an issue generating builds for specific platforms: https://github.com/dotnet/sdk/issues/527

[albertromkes]

No. After running dotnet build -r debian.8-32 I run into the same issue.

See blow screenshot:

Publish does produce the correct RID folder and files, but I cannot really test it because there's no ARM support yet for dotnet cli for my Raspberry PI 3 :(

[Sebosek]

@albertromkes I ran in similar issue, check your project.json and ensure, that followings is similar like this:

"dependencies": {
    "Microsoft.NETCore.App": "1.1.0"
},

"frameworks": {
    "netcoreapp1.1": {
        "imports": [
            "netstandard1.6",
            "portable-net45+win8"
        ]
    }
},

"runtimes": {
    "win10-x64": {},
    "debian.8-x64": {}
}

[vad710]

@Sebosek - I think that the situation that @albertromkes was describing is using the new tooling in csproj xml files since project.json is becoming obsolete

[albertromkes]

@Sebosek @vad710 Indeed. I am using the 'new' csproj file.

[Petermarcu]

@albertromkes , Is the only thing blocking you now the arm32 support so you can run the published output on RPi3? That will be coming soon.

[albertromkes]

@Petermarcu Yes. I'm watching the releases closely :)

[Petermarcu]

There is a zip of Ubuntu arm32 binaries linked here: https://github.com/dotnet/core-setup/issues/725#issuecomment-268705518

You could try running on that :)

[AlexGhiondea]

I ran into this as well and wrote a small msbuild target for this.

Basically, after the Publish target (which will publish the assets targeting the shared framework), invoke msbuild for each of the RuntimeIdentifiers specified.

<Project ToolsVersion="15.0">
  <Target Name="PublishAll" AfterTargets="Publish" 
          Condition="'$(RuntimeIdentifier)'=='' and '$(RuntimeIdentifiers)'!=''">
    <ItemGroup>
      <RIDsToPublish Include="$(RuntimeIdentifiers)" />
    </ItemGroup>

    <MSBuild Projects="$(MSBuildProjectFullPath)" Targets="Publish" 
             Properties="RuntimeIdentifier=%(RIDsToPublish.Identity)" 
             RemoveProperties="RuntimeIdentifiers"/>
  </Target>

  <Target Name="PublishRID" AfterTargets="Publish" 
          Condition="'$(RuntimeIdentifier)'!=''">
    <Message Importance="High" Text="Published $(RuntimeIdentifier)" />
  </Target>
</Project>

You can import this target into your .csproj and then dotnet publish will publish for all of the RIDs defined in your project.

[Petermarcu]

I thought they were adding that to the VS 2017 MSBuild story. Maybe not?

[AlexGhiondea]

That would be awesome! :)

[Petermarcu]

@srivatsn can you confirm?

[srivatsn]

A publishallrids target? No I'm not tracking that for 1.0

[JesseChisholm]

re: dotnet run ... vs. dotnet ...
The dotnet run ... expects the directory that contains the project.json file - builds it, runs it.
The dotnet ... expects the path to the resulting DLL, runs it.
IMHO: seems like a silly distinction.

[OlekRia]

"To run a published dll-
dotnet app.dll
Don't use "dotnet run"."

OK OK. But using dotnet run app.dll I can use --server.urls http://localhost:12345

How can I use another port than default 5000 in case of "dotnet run" ?

[jaxspades]

Hey all,

My csproj looks like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <RuntimeIdentifiers>win7-x64</RuntimeIdentifiers>
  </PropertyGroup>
</Project>

However, when I use build or publish, I still only get a dll, pdb, and other random output files. What am I missing for creating a standalone exe?

[svick]

@jaxspades It should be: <RuntimeIdentifier>win7-x64</RuntimeIdentifier>.

[jaxspades]

Still getting just a dll with that change.

[csells]

ditto. no exe output for me, either.

[jonstodle]

To get an exe you have to specify that you want to build for a specific runtime:

dotnet publish -c Release -r win10-x64

This will output the exe in bin\Release\netcoreapp1.0\win10-x64\publish. The output in the terminal only mentions the dll as that's your actual application, but it will output an exe as well.

The docs on this are available here: https://docs.microsoft.com/en-us/dotnet/articles/core/deploying/index#self-contained-deployments-scd

[Petermarcu]

There is a bug in the 1.0/1.1 tooling where the path it shows at the end of publish didn't point to the location of the published app. Curious if that's what people are hitting. You have to look in bin\Release\<TargetFramework>\<RuntimeIdentifier>\publish.

[rinebob]

Hi,
I was having the same problem but got it fixed. Here's what worked for me.

I went through the Publish SCD routine in the doc that @jonstodle provided, which leads to this page: [https://docs.microsoft.com/en-us/dotnet/core/deploying/deploy-with-vs]
in the SCD section it mentions the "Summary" section of the Publish dialog (access it by clicking the 'Configure' link to the right of the 'Target Location' field. * In the popup, make sure that the Deployment Mode is set to 'Self-contained' and the Target Runtime is 'win10-x64'.* Even after I changed all the settings in Debug/Build and Project Properties, this setting didn't get changed.

I hope this helps - too bad I'll never get that hour back but...