New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to run published console app? #77

Closed
ryanelian opened this Issue May 16, 2016 · 46 comments

Comments

Projects
None yet
@ryanelian

ryanelian commented May 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@oaiey

oaiey May 17, 2016

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.

oaiey commented May 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ryanelian

ryanelian May 17, 2016

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

dotnet

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

ryanelian commented May 17, 2016

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

dotnet

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

@Petermarcu

This comment has been minimized.

Show comment
Hide comment
@Petermarcu

Petermarcu May 17, 2016

Member

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.

Member

Petermarcu commented May 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ryanelian

ryanelian May 17, 2016

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?

ryanelian commented May 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@aL3891

aL3891 May 17, 2016

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

aL3891 commented May 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ryanelian

ryanelian May 17, 2016

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)

ryanelian commented May 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@aL3891

aL3891 May 17, 2016

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?

aL3891 commented May 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ryanelian

ryanelian May 17, 2016

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

ryanelian commented May 17, 2016

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

@aL3891

This comment has been minimized.

Show comment
Hide comment
@aL3891

aL3891 May 18, 2016

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": { }
  }
}

aL3891 commented May 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gulshan

gulshan May 23, 2016

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

gulshan commented May 23, 2016

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

@ryanelian

This comment has been minimized.

Show comment
Hide comment
@ryanelian

ryanelian May 26, 2016

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!

ryanelian commented May 26, 2016

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!

@ryanelian ryanelian closed this May 26, 2016

@jkristia

This comment has been minimized.

Show comment
Hide comment
@jkristia

jkristia May 29, 2016

@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

jkristia commented May 29, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mairaw

mairaw May 29, 2016

Contributor

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

Contributor

mairaw commented May 29, 2016

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

@mattcdavis1

This comment has been minimized.

Show comment
Hide comment
@mattcdavis1

mattcdavis1 Jun 28, 2016

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.

mattcdavis1 commented Jun 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
Contributor

svick commented Jun 28, 2016

@mattcdavis1

This comment has been minimized.

Show comment
Hide comment
@mattcdavis1

mattcdavis1 Jun 28, 2016

@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)?

mattcdavis1 commented Jun 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@svick

svick Jun 28, 2016

Contributor

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

Contributor

svick commented Jun 28, 2016

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

@mattcdavis1

This comment has been minimized.

Show comment
Hide comment
@mattcdavis1

mattcdavis1 Jun 28, 2016

yep - that worked. thanks!

mattcdavis1 commented Jun 28, 2016

yep - that worked. thanks!

@bitslasher

This comment has been minimized.

Show comment
Hide comment
@bitslasher

bitslasher Jul 10, 2016

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.

bitslasher commented Jul 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Jul 10, 2016

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.

davidfowl commented Jul 10, 2016

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 comment has been minimized.

Show comment
Hide comment
@tbird321

tbird321 Nov 4, 2016

This did not work for centos linux just for windows mac

tbird321 commented Nov 4, 2016

This did not work for centos linux just for windows mac

@vad710

This comment has been minimized.

Show comment
Hide comment
@vad710

vad710 Dec 14, 2016

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?

vad710 commented Dec 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@albertromkes

albertromkes Dec 28, 2016

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

albertromkes commented Dec 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Petermarcu

Petermarcu Dec 29, 2016

Member

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.

Member

Petermarcu commented Dec 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@vad710

vad710 Dec 29, 2016

@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: dotnet/sdk#527

vad710 commented Dec 29, 2016

@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: dotnet/sdk#527

@albertromkes

This comment has been minimized.

Show comment
Hide comment
@albertromkes

albertromkes Dec 30, 2016

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

See blow screenshot:

image

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 :(

albertromkes commented Dec 30, 2016

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

See blow screenshot:

image

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

This comment has been minimized.

Show comment
Hide comment
@Sebosek

Sebosek Jan 5, 2017

@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": {}
}

Sebosek commented Jan 5, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@vad710

vad710 Jan 5, 2017

@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

vad710 commented Jan 5, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@albertromkes

albertromkes Jan 5, 2017

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

albertromkes commented Jan 5, 2017

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

@Petermarcu

This comment has been minimized.

Show comment
Hide comment
@Petermarcu

Petermarcu Jan 5, 2017

Member

@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.

Member

Petermarcu commented Jan 5, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@albertromkes

albertromkes Jan 5, 2017

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

albertromkes commented Jan 5, 2017

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

@Petermarcu

This comment has been minimized.

Show comment
Hide comment
@Petermarcu

Petermarcu Jan 5, 2017

Member

There is a zip of Ubuntu arm32 binaries linked here: dotnet/core-setup#725 (comment)

You could try running on that :)

Member

Petermarcu commented Jan 5, 2017

There is a zip of Ubuntu arm32 binaries linked here: dotnet/core-setup#725 (comment)

You could try running on that :)

@AlexGhiondea

This comment has been minimized.

Show comment
Hide comment
@AlexGhiondea

AlexGhiondea Jan 20, 2017

Member

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.

Member

AlexGhiondea commented Jan 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Petermarcu

Petermarcu Jan 20, 2017

Member

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

Member

Petermarcu commented Jan 20, 2017

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

@AlexGhiondea

This comment has been minimized.

Show comment
Hide comment
@AlexGhiondea

AlexGhiondea Jan 20, 2017

Member

That would be awesome! :)

Member

AlexGhiondea commented Jan 20, 2017

That would be awesome! :)

@Petermarcu

This comment has been minimized.

Show comment
Hide comment
@Petermarcu

Petermarcu Jan 20, 2017

Member

@srivatsn can you confirm?

Member

Petermarcu commented Jan 20, 2017

@srivatsn can you confirm?

@srivatsn

This comment has been minimized.

Show comment
Hide comment
@srivatsn

srivatsn Jan 22, 2017

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

srivatsn commented Jan 22, 2017

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

@JesseChisholm

This comment has been minimized.

Show comment
Hide comment
@JesseChisholm

JesseChisholm Mar 24, 2017

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.

JesseChisholm commented Mar 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@OlekRia

OlekRia Apr 4, 2017

"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" ?

OlekRia commented Apr 4, 2017

"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

This comment has been minimized.

Show comment
Hide comment
@jaxspades

jaxspades Apr 5, 2017

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?

jaxspades commented Apr 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@svick

svick Apr 5, 2017

Contributor

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

Contributor

svick commented Apr 5, 2017

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

@jaxspades

This comment has been minimized.

Show comment
Hide comment
@jaxspades

jaxspades Apr 5, 2017

Still getting just a dll with that change.

jaxspades commented Apr 5, 2017

Still getting just a dll with that change.

@csells

This comment has been minimized.

Show comment
Hide comment
@csells

csells Apr 9, 2017

ditto. no exe output for me, either.

csells commented Apr 9, 2017

ditto. no exe output for me, either.

@jonstodle

This comment has been minimized.

Show comment
Hide comment
@jonstodle

jonstodle Apr 13, 2017

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

jonstodle commented Apr 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Petermarcu

Petermarcu May 2, 2017

Member

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.

Member

Petermarcu commented May 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rinebob

rinebob May 30, 2018

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...

rinebob commented May 30, 2018

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment