Runtime: Support framework-dependent apphost

[steveharter]

This is a placeholder to support a native executable (e.g. myapp.exe) that will find and use the shared framework. There are several scenarios, including global tools, that desire this functionality in the 2.1 timeframe.

Currently, a self-contained app always has a native executable but cannot use the shared framework, and a framework-dependent app is always dotnet.exe.

The likely implementation will consist of a native executable (apphost.exe renamed to .exe) that can either run in standalone or shared mode depending on the presence (or lack of) of runtimeconfig.json settings that specify the shared framework. For Linux\OSX, a new environment variable is likely required to specify the location of the shared framework to use; on Windows this is not necessary due to the well-known "Program Files" location.

Related scenarios: https://github.com/dotnet/cli/issues/6237, https://github.com/dotnet/core-setup/issues/196

[steveharter]

cc @srivatsn for your scenario (offline)

[Petermarcu]

@steveharter should we have a design meeting this week?

[steveharter]

@Petermarcu yes I am going to set one up this week. The basic proposal for the host is:
1) Modify the current host code to support a framework-dependent apphost
2) Add a new environment variable (say %DOTNET_PATH%)
3) This environment variable will be used by apphost to find the hostfxr and in turn find the frameworks

Additional options (not required for initial functionality; but want to assume forward-compatibility):
a) Add support for runtimeconfig.json (dotnetPath) and command line (--dotnet_path) which will override the environment variable
b) Embed the default path into the apphost for the appropriate distro, so that the environment variable doesn't have to be set for the "happy path". The environment variable (and runtimeconfig\command-line) would override this.

[itadapter]

@steveharter looks like your approach with env var will solve the problems we have now with adoption of core with legacy dev groups. what do you think is a realistic ETA for shipped binary so regular user can start benefiting?

[steveharter]

@itadapter can you explain your scenario with legacy dev groups?

ETA is pending; we'd like to get basic support in for 2.1, but no guarantees due to tight schedule.

[itadapter]

@steveharter the primary "culture shock" of using .core is "i dont see exe" - I know this is stupid, but when I tried to push a core solution instead of legacy 4.5 they started talking about "learning curve" "things drastically different" - the funny thing is, the code in question is basically plain BCL 3.x era, so it converted to Net standard 2 almost 1:1 (except for image drawing) - the selling point breaker was "dotnet" cli

bottom line: if I did not have to dance in front of corporate "board" to convince that net core is basically 1:1 to net framework (for their app) - I would have sold .core, instead they still sit on Net 4.5 VS 2012 :)

[Petermarcu]

@itadapter so the main point is that they really just want a .exe. If you are able to build an application that can be launched as myapp.exe instead dotnet myapp.dll you are happy?

[itadapter]

@Petermarcu there are many issues noted in the relevant threads by many:

https://github.com/dotnet/cli/issues/6237#issuecomment-372680051
to list a few:

1. if you use cli tools, it is inconvenient to write "dotnet tool.exe -switch" instead of " tool -switch" (same on Linux)
2. In process explorer you now see "dotnet.exe" for multiple entry points, instead of meaningful module names like "a.exe" "b.exe" etc.

there are many other problems that need to be considered if you make an exe - header flags for process etc..

[sqlBender]

I can vouch for dev friction getting in the way of adoption. The decision to force even basic apps to be portable with all the baggage that entails, forces developers that do not need portability to still have to deal with the tooling getting in the way of their simple apps. If we can't write simple apps comfortably in .net core, then we won't be writing complicated ones either. Having to drop into a command line to execute my hello world app using a string I had to Google, er. Bing... does not build in confidence...

[BobbyCannon]

I can also vouch for development friction getting in the way of my adoption of .NET core. I don't care about cross platform but I also don't mind it. However when I cannot simply create a new solution, build it, then deploy it without having to "bing" for solution... it's very frustrating. Time to learn a new process to create a .NET console app?... seems silly and it is not very clear. Am I turning into a Grumpy Old Man?