dotnet run not working for netstandard1.6 console app

[livarcocc]

From @VanCoding on April 20, 2017 10:7

Steps to reproduce

Create a hello world application, like described here in the section Deploying a self-contained deployment with a smaller footprint. Which results in a csproj file like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netstandard1.6</TargetFramework>
    <RuntimeIdentifiers>win7-x64</RuntimeIdentifiers>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NETCore.Runtime.CoreCLR" Version="1.0.2" />
    <PackageReference Include="Microsoft.NETCore.DotNetHostPolicy" Version="1.0.1" />
  </ItemGroup>
</Project>

Then run dotnet run

Expected behavior

The projects gets compiled and then started

Actual behavior

It prints out:

Unable to run your project.
Please ensure you have a runnable project type and ensure 'dotnet run' supports    this project.
The current OutputType is 'Exe'.

Environment data

.NET Command Line Tools (1.0.3)

Product Information:
Version: 1.0.3
Commit SHA-1 hash: 37224c9917

Runtime Environment:
OS Name: Windows
OS Version: 6.1.7601
OS Platform: Windows
RID: win7-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.3

Notes

When I use netcoreapp1.1 instead, it works. But with netstandard1.6 it does not.

Copied from original issue: dotnet/cli#6364

[livarcocc]

From @svick on April 20, 2017 11:45

Why would you expect that to work? .Net Standard is not an actual runtime, so it makes sense you can't run apps on it.

A similar issue: https://github.com/dotnet/corefx/issues/18217.

[livarcocc]

From @VanCoding on April 20, 2017 11:57

Well, because I did target it before I upgraded my project.json file to project.csproj today, and it worked. But after the upgrade, it does not.

Plus, if I do dotnet publish, I get an exe file, which I can execute.

If I understand that correctly, netstandard not being a runtime is the reason why I have to add those 2 references.

[livarcocc]

From @dasMulli on April 20, 2017 12:46

The issue here is that the SDK targets don't define the necessary values for RunCommand and RunArguments as they are conditioned the target framework: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Sdk.targets#L291

Also, I don't think the scenario will still work with 2.0 tooling and netstandard 2.0..

However, this works as a workaround (warning: may cause allergic reactions):

<Project>
  <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netstandard1.6</TargetFramework>
    <RuntimeIdentifier>osx.10.12-x64</RuntimeIdentifier>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NETCore.Runtime.CoreCLR" Version="1.0.2" />
    <PackageReference Include="Microsoft.NETCore.DotNetHostPolicy" Version="1.0.1" />
  </ItemGroup>
  <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />
  <PropertyGroup>
    <RunCommand Condition="'$(RunCommand)' == ''">$(OutDir)/dotnet$(_NativeExecutableExtension)</RunCommand>
    <RunArguments Condition="'$(RunArguments)' == ''">exec &quot;$(TargetPath)&quot; $(StartArguments)</RunArguments>
  </PropertyGroup>
</Project>

[livarcocc]

@dasMulli Is correct. This won't work in 2.0 and in 1.0 using netstandard1.6 for the small footprint self contained app is not correct. @mairaw this is the issue with documentation that I was telling you about yesterday.

I believe, the correct way to solve this is to use either netcoreapp1.0 or netcoreapp1.1 and true and then add PackageReferences to Microsoft.NETCore.Runtime.CoreCLR, Microsoft.NETCore.DotNetHostPolicy and System.Console.

Meanwhile, I will move this issue to the docs repo.

[guardrex]

This isn't directly related to this issue; but since it deals with the same type of deployment, let's keep the tracking issue on publishing an SCD small footprint web app cross-referenced here: https://github.com/dotnet/cli/issues/5769

@rpetrusha and I briefly touched on this. We're not going to address or note anything regarding those problems in the deployment doc at this time, since (a) the doc only addresses small footprint console apps, and (b) nobody else is asking/complaining (at least right now).

[mairaw]

Thanks @livarcocc!

@guardrex let's just make sure that the scenarios we're covering on docs are correct though. My understanding by looking at this is that we're giving the wrong steps and we shouldn't be telling people to target netstandard1,6 in the small footprint scenario.

We're shipping some updates to the deployment docs today, so let's check to see if the issue still persists after that.

[guardrex]

AFAIK the TF is fine for deployed apps. I think the issue is just with dotnet run. My confusion is more like ... If u get an EXE, one doesn't need to dotnet run it ... just double click the EXE. I only ever worked with web apps for this deployment type. Ron knows more about the console app small footprint SCD.

[rpetrusha]

No, for the published self-contained app, dotnet run is not needed -- only the executable.

[guardrex]

So if the doc gets a blurb on this it will just be a note along the lines that dotnet run cannot be used to start the app.

[dasMulli]

What are the reasons to keep the doc?
It doesn't seem to ever have been an "official" way of creating applications except for this documentation. AFAIK there aren't any unit or end-to-end integration tests on any tooling repo and it only worked by making use of side effects of the way NETStandard.Library and Microsoft.NETcore.App have been constructed.
Since those packages are now built differently, as well as the requirement so modify apphost.exe when deploying self-contained, creating such a deployment will be riddled with workarounds.
Additionally, If too many assemblies are missing from the resulting deployments, some netstandard 2.0 compatible packages might not work hard-to-debug runtime failures.

[guardrex]

IIRC there was ... back in project.json days ... something like a 10-20% decrease in app footprint when publishing this way. Of course, the returns diminish as more and more packages are used in an app. For very small apps, the difference in deployment size was noticeably good ... less disk space required ... faster deployment time. For a large app, the difference will probably be negligible.

[guardrex]

in 1.0 using netstandard1.6 for the small footprint self contained app is not correct.

For the changes that @rpetrusha just merged, he did put in an update to 1.1 for netstandard1.6.

[guardrex]

@mairaw The solution is to remove the small footprint SCD sections/mentions. It doesn't work under 2.0 and was never really supported well anyway. Shall I go ahead and 🔪 it out?

[rpetrusha]

@guardrex, Yes. I'll open a PR to do it.