'dotnet run' fails for self-contained applications

[eerhardt]

Using this project on a windows machine:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeFrameworkVersion>2.0.0-beta-001482-00</RuntimeFrameworkVersion>
    <RuntimeIdentifier>win7-x64</RuntimeIdentifier>
  </PropertyGroup>

</Project>

$ dotnet restore
$ dotnet run

Raises an error:

A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'F:\DotNetTest\DependencyTest\bin\Debug\netcoreapp2.0\'.

Notes

When initially designing .NET Core for MSBuild, we wanted the experience that "framework-dependent vs. self-contained was a publish time decision". That mean that you can take the same .csproj and without modifying it, publish as a "framework-dependent (a.k.a. portable/shared framework)" or a "self-contained" app. In order to support that, a decision was made that dotnet build and dotnet run were always framework-dependent.

However, this turns out to not be a great decision because there are scenarios where you want to target a .NET Core runtime that you haven't installed on the machine. In this case, you explicitly choose that you are a self-contained app, and you target the framework version (like a nightly build of Microsoft.NETCore.App) that you want. You still should be able to dotnet run your application. The only thing that works today is to dotnet publish and then execute the app, which IDEs don't typically do.

To enable this, I think the things that need to be done are:

1. Copy the hostfxr and hostpolicy assemblies to the output folder
2. (Optional) Copy the dotnet executable to the output folder and rename it to $(TargetName)[.exe]
   • If we do this, we also need to change the "Run Information" to point to this executable instead of the dotnet on the path.
3. Set the output folder to have the RID in it.
   • This might not be required, but that's how project.json based projects did it.
     the dotnet muxer.

See https://github.com/dotnet/cli/blob/rel/1.0.0-preview2.1/src/Microsoft.DotNet.Compiler.Common/Executable.cs#L96-L108 for how this worked on project.json based projects. Specifically the CoreHost.CopyTo(_runtimeOutputPath, _compilerOptions.OutputName + Constants.ExeSuffix); part, which does the first two steps above.

[srivatsn]

This is the same as #527? @nguerrera

[Petermarcu]

Does this mean F5 doesn't work on self contained apps?

[nguerrera]

I think so. And what Eric describes is the fix I'm thinking about. I'll leave them both open for now.

[nguerrera]

I'm looking at making this change today.

[Petermarcu]

@dougmsft is hitting this as he tries to use .NET Core.

[eerhardt]

This is the same as #527?

Yes, I believe so. dotnet run not working for self-contained apps is a consequence of not having the write build output for self-contained apps.

Closing this and adding dotnet run to the scenario on #527.