Sdk: app.runtimeconfig.json is not optional

[sstevenkang]

According to this documentation Runtime Conifguraiton Files, app.runtimeconfig.json is an optional configuration file. However, it doesn't look like it's the case.

Steps to reproduce

I have the following test app:

using System;
namespace test {
    class Program {
        static void Main(string[] args) {
            Console.WriteLine("Hello World!");
        }
    }
}

Run the following commands in sequence:

dotnet publish
cd bin\Debug\netcoreapp2.0\publish
del test.runtimeconfig.json
dotnet test.dll

Expected behavior

Application writes to console:

Hello World!

Actual behavior

Dotnet executable reports the following error:

A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'd:\workspace\test\bin\Debug\netcoreapp2.0\publish\'.

Environment data

dotnet --info output:

.NET Command Line Tools (2.0.0)

Product Information:
 Version:            2.0.0
 Commit SHA-1 hash:  cdcd1928c9

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

[MNF]

The scenario is not correct. “The file is optional”means that developer doesn’t need to create it manually. But it is not allowed to go to bin folder and delete automatically generated files.

However the confusing error message about missing hostpolicy.dll may be caused by multiple reasons including attempt to run dotnet MyApp.Exe instead of just MyApp.Exe (https://stackoverflow.com/questions/38332512/the-library-hostpolicy-dll-required-if-run-from-deploy-folder-but-emitentry/38333053#38333053)

[livarcocc]

@sstevenkang the file is optional because it is not needed for self-contained apps. It is only required for portable applications.

@MNF running dotnet is the correct command when you are running a portable application. If you are running a self-contained app, then you should use app<.exe>.

I am updating the linked document to make it clear when it is optional.

[onema]

TLDR;
If you are getting a Could not find the required '[app-name].runtimeconfig.json' error add the following to the PropertyGroup in your .csproj

<GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>

---

The language here is really misleading. If the *runtimeconfig.json why do I have to include the following statement to my *.csproj, but without it, my app doesn't run?

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles> <====?
  </PropertyGroup>
</Project>

Without it, the file is not created and my FDD app doesn't run and it fails with the following message

"Could not  find the required '[app-name].runtimeconfig.json'.  This file should be present at the root of the deployment package."

[livarcocc]

@onema If you have <OutputType>exe</OutputType> in your project, then we will generate the runtimeconfig.json for you without having that property set. As it is, your project is a library and not an app.

[MeTitus]

I very much thing this issue is still out there.

I have the latest update to VS2017 and without this setting

<GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>

the runtimeconfig.json file is not generated.

I have addded runtimeconfig.template.json to the root project, as per https://github.com/dotnet/cli/issues/9126

and it still does not work. I don't think you guys could have messed this more even if you wanted.

[mwpowellhtx]

@livarcocc Question, my .runtimeconfig.json file is being generated. That's great. However, it is not included with the usual project output, i.e. when I make a <ProjectReference/>. Is that normal? How do I tell dotnet which runtimeconfig(s) to use otherwise?

[mwpowellhtx]

@livarcocc Maybe a separate issue, there are additional dependencies my CLI tool has in the form of <PackageReference/>. These are not private assets, they should be traveling with the build output to projects otherwise making the <ProjectReference/>. I can possibly workaround that by making the <PackgeReference/> in the destination project, but I think that should be unnecessary unless I was making a stronger use of the dependency, which I am not in this case.