When necessary runtime isn't installed, is there a method to make the error message show specific runtime info without using an installer?

[xinding1121]

I have a WPF application that needs .NET 6 Desktop Runtime installed on user's device. When the desktop runtime is missing, the error alert dialog not always shows the specific runtime information which I expect to be '.NET Desktop Runtime 6'. Seems that behaviors vary on different devices. I'm not sure if it's about the OS version.

We have some cases like:

1. only show .net is needed:
   
2. shows that it needs .net core but is misguiding. Actually we need .net 6 desktop runtime:
   
3. shows the correct runtime we need and it's what we expect:
   

Why the behaviors vary on different devices? Is there any method to make the message always show the specific runtime information? Any advice or redirection will be appreciated.

[huoyaoyuan]

Some context for when this dialog was improved: #3761 #3811

[xinding1121]

Thanks a lot. I went through the items and the requirements were similar with mine.

[vitek-karas]

Very recently we've made improvements to this area:
#67022 - which includes improvements to error messages (although the main focus is disabling MLL)
#67564

[xinding1121]

@vitek-karas Thanks very much for the reply and associated items. Is there any requirement for the OS version or .NET framework version to show the new improvements, or do we need to do some configuration? From the conversation I get that disabling MLL takes effect by default since .NET 7 and our WPF's target framework is .NET 6 and is compatible with windows 7. I'm not sure if the improved error messages also requires .NET 7.

From my side we also found that in Windows 11, the specific runtime information(.NET Desktop Runtime 6.0.3(x64)) is shown, as the last screenshot in my question while in Windows 10 there isn't.

[vitek-karas]

These changes I mentioned are only available in very recent .NET 7 builds - they should have no tie to Windows version or any other piece of software. They should be present in apps targeting net7.0 and built by very recent .NET 7 SDK (it actually might not be in the nightly build yet, but should be soon).
Currently I'm not aware of any plans to backport these to .NET 6 or below.

[vitek-karas]

Sorry - I think I misunderstood. The difference between the two dialogs is that the one without detailed information is presented if there is no .NET installed on the machine (has nothing to do with .NET Framework, it means there's no .NET 5, 6... ).

This is because the code which can actually extract the information which version the app needs actually lives in the installed runtime. The app alone without the runtime only knows that it needs A runtime - and a so called "host version", which typically maps to the runtime version, but it may not.

The second (better) dialog is produced if there already is .NET runtime on the machine.

The above PRs tried to improve these as much as possible, but there is still some difference due to the layering of capabilities described above.

[xinding1121]

I see. Thanks. Do you have any ideas on why the 2nd figure in my original question shows that the application needs .NET Core? it misleads our customers. Any insight or redirection will be appreciated.

And can I treat "The second (better) dialog is produced if there already is .NET runtime on the machine." as When there is already a .net runtime installed but not exactly the one that the application needs, it shows the better dialog below?

[vitek-karas]

For the second question:

When there is already a .net runtime installed but not exactly the one that the application needs, it shows the better dialog below?

Yes - that's exactly when this happens.

For the first one: What version of .NET is the app targeting? I can't find that exact string anywhere, but maybe I'm looking in the wrong place.
In any case, it's very unlikely we would backport a change to it.

[xinding1121]

For the first one: What version of .NET is the app targeting? I can't find that exact string anywhere, but maybe I'm looking in the wrong place. In any case, it's very unlikely we would backport a change to it.

The app is targeting .NET 6 and the required runtime is .NET 6 Desktop Runtime, so we have no idea why the error message shows '.Net Core' in some cases. We want to know why it shows '.NET Core' and if there won't be changes I think my teammates and I could try other solutions to let customers know the requirement.

[vitek-karas]

I still can't figure out where is that dialog from. I tried it locally - hello world WinForms app targeting .NET 6. Run it in an environment with no .NET installed, I get this:

Can you please try this:

set COREHOST_TRACE=1
set COREHOST_TRACEFILE=host.txt
<run the app from this command line>

This should produce host.txt - it contains information about the local machine like paths, env. variables and so on. Please make sure you're OK to share the information from that file before sharing it. Among other things this contains the exact version of the host. For example I see this:

--- Invoked apphost [version: 6.0.2, commit hash: 839cdfb0ecca5e0be3dbccd926e7651ef50fdf10] main = {

[xinding1121]

Sure. I tried the command lines. I'm also from MSFT so I sent 'host.txt' files to your work email yesterday in case of privacy issues:) Hope it was sent well.

[vitek-karas]

Thanks @xinding1121 for the trace logs.
The difference is due to usage of single-file.

There are basically 3 cases, each with slightly different error message:

• There's no .NET runtime on the machine
• There's an old .NET runtime and the app is a framework dependent single-file. The single-file feature needs a reasonably new runtime to work at all (as it was added later on). Note that the host doesn't know at this point which exact version it will need (it's failing too early in the process).
• There's a .NET runtime but not the necessary version (missing framework, the host knows exactly what is missing)

The second scenario (FDD single-file) is currently failing with error message containing ".NET Core" string, which is wrong.
I opened a PR #68260 to fix that.

[xinding1121]

We checked the runtimes on the machines.

The second scenario (FDD single-file) is currently failing with error message containing ".NET Core" string, which is wrong. I opened a PR #68260 to fix that.

Yeah exactly. Our application is a framework dependent single-file. On one of the two machines there's an old runtime(.net 3.1 desktop runtime) and it showed '.Net Core'.

On another device there're several runtimes but not the necessary runtime:

message on this machine is:

Much appreciated.

[vitek-karas]

Thanks a lot for confirming the behavior. Once the PR #68260 is in, with .NET 7 the dialogs should be more consistent and should not contain any .NET Core mention anymore.