Non-selfcontained RID-specific app should copy host executable to build output

[dasMulli]

TL;DR
Combination of RuntimeIdentifier + SelfContained=false doesn't work well for development work (dotnet run, visual studio F5).

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeIdentifier>win-x86</RuntimeIdentifier>
    <SelfContained>false</SelfContained>
  </PropertyGroup>

Scenario / Repro steps:

• Create a console app
• Add native 32-bit dlls to PInvoke into
• Realize you now need to make sure you run 32bit only and are locked into a RID
  • add <RuntimeIdentifier>win-x86</RuntimeIdentifier> to the csproj
• dotnet run works just fine now since there is a 32 bit host executable copied to the output directory which resolves the 32bit runtime. Visual Studio also runs the app just fine.
• Publish once and realize you don't need to publish self-contained. Or have problems using dotnet publish --self-contained because it is passed as a global parameter to all reference projects and some may error out (Cannot publish core console app + core app library tests #1834)
  • Put <SelfContained>false</SelfContained> into the csproj file.
• dotnet run and Visual Studio run no longer work because it falls back to calling dotnet the.dll which fails to load 32-bit (native) assemblies.

Can the generation of the native host be turned on even though SelfContained is false for build output only?

There may be some additional advantages in also copying this host without the self-contained framework for publish - (https://github.com/dotnet/cli/issues/6237)

The advantage of this host is that it launches with the right bitness and there is no need to put the 32bit dotnet.exe on the PATH or use a 32bit SDK.

[peterhuene]

I'm currently working on addressing dotnet/cli#6237 for publish.

The current thinking (the PR on the CLI side hasn't been put up yet) is to publish with something like:

dotnet publish -r win-x64 --self-contained=false --with-apphost

This would publish a framework-dependent application with the apphost generated. If --with-apphost is not specified (obviously the default), then the apphost isn't generated and users are expected to run with dotnet foo.dll.

We don't yet have corresponding options for dotnet build, but you can obviously pass the related MSBuild properties on the command line. Right now, when you pass --runtime to build, it implicitly makes it a "self-contained" build: creating the apphost and copying the hostfxr/hostpolicy to the output directory, but not the entire framework (that only happens on publish). Specifying -p:SelfContained=false and -p:UseAppHost=true (the underlying property for publish's --with-apphost option), then you get a framework-dependent apphost build.

I'd like this improved to maybe: dotnet build -r win-x86 --with-apphost (or something along those lines). I'm not sure a "self-contained" build makes sense or is even intentional when building with a runtime specified.

However, dotnet run only respects the --runtime option up until it tries to determine the command to run. Because the specified runtime isn't passed through during this evaluation, the project is evaluated as not being "self-contained" and thus the run command is always dotnet exec rather than the native apphost, unless RuntimeIdentifier is specified in the project itself.

This is something I'd also like to fix for 2.1.4xx.

So even with #2282 merged, dotnet run would need be fixed to pass through the RuntimeIdentifier and UseAppHost properties when determining the run command. With that done, you could theoretically run (assuming a similar --with-apphost is implemented for run) with:

dotnet run --runtime win-x64 --with-apphost

[dasMulli]

That's a great improvement!

I'd argue that the host should always be used / created into the build output for running (including amending RunCommand) and be an option for publishing (-p:PublishAppHost ?).
But again that's probably specific to the "I absolutely need to use win-x68 when my first dotnet.exe on the PATH is a win-x64" as described above. But now there's a way to hack it together.

[peterhuene]

I was going with opt-in behavior because some users might be sensitive to what ends up in the build output directories (custom publishing / packaging, maybe?). I'm definitely open to discussing it, though.

Whatever we decide, I'd like the dotnet build, dotnet publish, and dotnet run to be consistent with respect to what options they use for self-contained vs. framework-dependent building/publishing/running.

[dasMulli]

Looking at the milestone, I totally agree with opt-in for minor versions (and then not changing it afterwards).

[dasMulli]

So if this works using

<PropertyGroup>
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
  <SelfContained>false</SelfContained>
  <UseAppHost>true</UseAppHost>
</PropertyGroup>

or similar (including RunCommand pointing to the host), just close this issue 😄

[peterhuene]

Hi @dasMulli:

With dotnet/cli#9460 merged and out of the release/2.1.4xx branch, what you have above is sufficient to generate an executable for a framework-dependent publish.

Let me know if you have any questions/feedback/concerns. Thanks!