Runtime: 3.1 Runtime prompt fails if .NET Core 2.x runtime is installed

[Symbai]

With .NET Core 3.1 the apphost now prompts on missing .NET Core runtime which is amazing. Sadly the application still silently crashes in the following scenario:

• .NET Framework 4.7 or higher installed
• .NET Core 2.1 Runtime installed

In such a scenario no prompt is shown, not even an entry in the event viewer. It might be caused by the core runtime is installed but the "desktop" stuff is not. However there should be definitely a prompt.

Demo:

Related https://github.com/dotnet/core-setup/issues/8620 and https://github.com/dotnet/core-setup/issues/8222
ping @dagood @elinor-fung

previously posted on https://github.com/dotnet/core-setup/issues/8933

[dagood]

Can you try running the app in a console to see if anything's logged to stderr/stdout?

I'm not completely sure something will show up there (or if we need to know to diagnose this), but maybe it'll get this a bit further until the host folks can chime in.

/cc @vitek-karas as well.

[vitek-karas]

@elinor-fung

I assume you're trying to run 3.1 app, right?
Please run it from console (it will not show anything either - I'm pretty sure), but before that set COREHOST_TRACE=1 and COREHOST_TRACEFILE=t.txt. The created t.txt should have all the details. It may contain paths from your machine, so please make sure that you're comfortable sharing those with us.

[Symbai]

This is a .NET Core 3.1 WPF 64bit application.

@vitek-karas content of t.txt:

Tracing enabled @ Fri Dec  6 16:55:35 2019 GMT
--- Invoked apphost [version: 3.1.0, commit hash: 65f04fb6db7a5e198d05dbebd5c4ad21eb018f89] main = {
WpfApp4.exe
}
Redirecting errors to custom writer.
The managed DLL bound to this executable is: 'WpfApp4.dll'
Can't get the size of the SDK location registry value or it's empty, result: 0x2
Using global installation location [C:\Program Files\dotnet] as runtime location.
Reading fx resolver directory=[C:\Program Files\dotnet\host\fxr]
Considering fxr version=[2.1.14]...
Detected latest fxr version=[C:\Program Files\dotnet\host\fxr\2.1.14]...
Resolved fxr [C:\Program Files\dotnet\host\fxr\2.1.14\hostfxr.dll]...
Loaded library from C:\Program Files\dotnet\host\fxr\2.1.14\hostfxr.dll
Invoking fx resolver [C:\Program Files\dotnet\host\fxr\2.1.14\hostfxr.dll] v2
Host path: [C:\Users\Bla\Desktop\WpfApp4.exe]
Dotnet path: [C:\Program Files\dotnet]
App path: [C:\Users\Bla\Desktop\WpfApp4.dll]
Probed for and did not resolve library symbol hostfxr_set_error_writer

Only when .NET Core Runtime 2.x is installed and no other .NET Core versions there is no prompt and the application silently crashes. I can instantly reproduce this on a fresh system including Windows 10 sandbox.

Test app:
netcoreapp3.1.zip

I did some more tests and here are the results:

| Installed Runtime | Shows missing .NET Core 3.1 prompt |
| ------------- | ------------- |
| No runtime | Yes |
| .NET Core 2.x runtime | No |
| .NET Core (ASP) 3.0.1 runtime | Yes |
| .NET Core 3.0.1 Runtime | Yes |
| .NET Core 3.0.1 Runtime + Desktop Runtime | Yes |

The checks behaves as expected in all cases except on .NET Core 2.x runtime.

[vitek-karas]

I think I know what's going on... and it's a bug unfortunately.

The problem is that the first thing the host does is search for hostfxr. It does find one so that's why it doesn't show "missing runtime". But then it looks for 3.0 functionality in it and that fails. Since apphost only needs to be forward compatible, it simply fails when the hostfxr is of lower version than necessary. Unfortunately it's not one of the errors which lead to the dialog - which was an oversight in the original implementation.

This should probably lead to missing runtime dialog - as that would guide users to install 3.0/3.1 runtime. (It can't really lead to missing framework as that functionality is in hostfxr itself).

[Symbai]

Can this bug be fixed so it prompts for missing .NET Core 3.1 runtime or will this be something that is out of scope?

[vitek-karas]

I was actually a bit wrong. The above described failure would also cause no dialog but it's not the reason for the issue reported here. The issue here is that 2.* hostfxr doesn't support custom error writers, and so the apphost gets not error message back from the hostfxr call it makes, only error code. Unfortunately the code is currently written such that in this case it will not report the error in any way.

This is a bit harder problem. Unfortunately the interfaces between the various hosting layers don't differentiate between error codes from the hosting/runtime and exit code from the application. So if the app returned the exit code 0x80008096 it looks exactly like a missing framework error (without the custom error writer support). I'm a bit hesitant popping up a dialog for apps which return such exit code about missing framework, even if there's no such error.

[mateoatr]

Following up the discussion on the PR attempting to fix this bug:

The only (meaningful) scenario in which this bug happens is whenever an end user tries to run a WPF app but doesn't have any version of hostfxr that can set a custom error writer (that is, a version of hostfxr >= 3.0).

My proposal here is to:

1) Check for the ability to set a custom error writer.
| Yes -> No bug.
| No ->
2) Check if we get a FrameworkMissingFailure.
| Yes -> This means that we're trying to run a WPF app, show error message on a dialog.
| No -> Great, we're good.

As for the error message, which I think is the tricky part here, I think that from the end user perspective it could be a little bit missleading/confusing to either prompt To run this application, you must install .NET Core. or a framework ... was not found.. I think that a more helpful error message could be: To run this application you need a version of .NET Core higher than the currently installed.

And redirect them to: https://dotnet.microsoft.com/download?framework=Microsoft.NETCore.App&arch=x64&rid=win10-x64&apphost_version=<apphost_version>

@vitek-karas @elinor-fung @Symbai @samsp-msft

[vitek-karas]

It might be a good idea to include at least some indication of the .NET Core version we're looking for (based on the apphost version) - but the wording needs to be careful since the version will not be a perfect match. Maybe we should take just the major/minor pair from the apphost version...
So something like: "The app seems to require at least .NET Core 3.1".

The URL as described above is somewhat misleading:

https://dotnet.microsoft.com/download?framework=Microsoft.NETCore.App&arch=x64&rid=win10-x64&apphost_version=<apphost_version>

The server will probably have a hard time doing the right thing:

• We don't know that it's Microsoft.NETCore.App framework which is missing. In fact the most likely case (almost 100% cases) is that it's the Microsoft.WindowsDesktop.App framework which is missing.
• In terms of behavior this is much closer to the "missing runtime" case which generates URL like this:

https://dotnet.microsoft.com/download?missing_runtime=true&arch=x64&rid=win10-x64&apphost_version=<apphost_version>

I think something like this would be better:

https://dotnet.microsoft.com/download?missing_runtime=true&gui=true&arch=x64&rid=win10-x64&apphost_version=<apphost_version>

• missing_runtime=true - this indicates to the server that we don't actually know the framework we need (similar to no hostfxr found - in this case it's basically the same since we can't get the right info from hostfxr). Server would know to deduce the version from the apphost_version, unlike the "missing framework" case where it gets the desired version in the URL.
• gui=true - this indicates that we're running a GUI application. Server would use this to make sure to offer installer with support for GUI applications - in our case the installer with Microsoft.WindowsDesktop.App framework in it. Since offering just the core runtime or ASP.NET will not help in this case.

[vitek-karas]

/cc @richlander @samsp-msft @danmosemsft
Please review the proposal above and the discussion about the URL as this has server side implications (to some degree).

[richlander]

That sounds good. I think making the behavior as simple as possible on the client side (as opposed to the server) is the best plan. So, gui/no-gui makes sense to me.

I'm not keen on the "you need a higher version of .NET Core" approach, for two reasons:

• That won't mean much to a lot of users.
• We also need to handle the lower version case, and then deal with localization, too. Not worth it.

This is the .NET Framework version of this dialog. I like how simple it is (except that it mentions the framework version twice).

[vitek-karas]

The problem is that due to the API limitations we don't know the version of .NET Core the app needs (For that we would have to parse the .runtimeconfig.json which is the job of hostfxr, but because we're dealing with old hostfxr we don't have the API to report the version to the apphost). The only version information we have available is the version of the apphost itself. That should be "close" to the desired version of .NET Core, but it won't be precise. That's why I suggested that imprecise version might be preferable (major.minor only). We also won't be able to specify which framework we need - just that we need ".NET Core" (as a whole).

[Symbai]

The prompt from @mateoatr is only a fallback solution that triggers in one particular case: When the user has installed .NET Core 2.x runtime and nothing else.

It won't trigger when:

• User has no .NET Core runtime installed
• User has .NET Core >3.x runtime but the wrong one

In these case the normal .NET Core runtime is missing prompt will be used. So I wouldn't put too much weight into the message and its information in @mateoatr PR as long as it's clear and redirects to the correct download page.

The older .NET Core 2.x becomes, the less his prompt will be shown at all.

[richlander]

I now understand why the text was chosen @ https://github.com/dotnet/runtime/issues/617#issuecomment-571825146.

How about this wording:

"To run this application, you need to install a newer version of .NET Core.

Would you like to download it now?
"

[mcarrilloco]

Hi. I am currently working on an application and hitting this issue. I just wanted to ask what are the plans for this fix. When will it be included in a release of dot net core?

[Symbai]

It has been backported to 3.1.3 (besides .NET 5). The current released version for end users is 3.1.2 so you still have to wait.