Include searched locations in error message when host cannot find a .NET install

[agocke]

This is mostly focused around when users install dotnet using a zip/tarball instead of an installer or package manager.

There are two issues:

• If the user hasn't installed dotnet to global isntall directory or set DOTNET_ROOT, then the error message should mention where it looked for dotnet (and didn't find it)
• If the user passes a native file, the error message is:

Could not execute because the specified command or file was not found.
Possible reasons for this include:

• You misspelled a built-in dotnet command.
• You intended to execute a .NET program, but dotnet-bin/Debug/net10.0/hello does not exist.
• You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.

This should instead have an error message saying that the target file was found, but is not a .NET assembly.

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

For the first case, we went for an aka.ms link with troubleshooting details and a download link instead:

You must install .NET to run this application.

App: /home/elinor/helloworld/bin/Debug/net10.0/helloworld
Architecture: x64
App host version: 10.0.0-preview.3.25171.5
.NET location: Not found

Learn more:
https://aka.ms/dotnet/app-launch-failed

Download the .NET runtime:
https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=linux-x64&os=ubuntu.22.04&apphost_version=10.0.0-preview.3.25171.5

As an end-user-facing message, it seemed like a good balance of pointing the user in the right direction without having all our implementation details in the message.
cc @richlander

For the second case, the message is coming from the SDK. Anything that isn't a .dll/.exe gets passed to the SDK to handle.

Without from the host, it is:

The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'dne' does not exist or is not a managed .dll or .exe.
  * You intended to execute a .NET SDK command:
      No .NET SDKs were found.

Download a .NET SDK:
https://aka.ms/dotnet/download

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found

Maybe the SDK error could be changed to be a bit more similar to the host one in format and also call out '... or is not a managed assembly' in its second bullet.

[agocke]

This seems like it might be misleading:

You must install .NET to run this application.

If we did actually find a .NET installation, this isn't correct. Even if we didn't find an installation, it might just be in a place we didn't look. Rather than try to hint to the user what went wrong, I think we should just tell them.

What happened was: we expected a matching runtime at one of the given places, and we didn't find it.

[agocke]

I should mention, this was due to real user feedback on Linux, where they ran the apphost after building using a tarball, but it didn't work. The purpose of the apphost itself isn't necessarily immediately clear, so this failure mode didn't help in clarifying.

They could have read the info behind link, but let's be honest here 😄

[agocke]

For the second case, the message is coming from the SDK. Anything that isn't a .dll/.exe gets passed to the SDK to handle.

Is this intended behavior? If the user passes a file but it's not a managed binary, we interpret it as a potential SDK command?

[elinor-fung]

If we did actually find a .NET installation, this isn't correct. Even if we didn't find an installation, it might just be in a place we didn't look. Rather than try to hint to the user what went wrong, I think we should just tell them.

We have a slightly different message when we do find a .NET installation, but it doesn't have the required frameworks. We'll list what we needed and we did find - for example:

You must install or update .NET to run this application.

App: /home/elinor/helloworld/bin/Debug/net10.0/helloworld
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '10.0.0-preview.6.25302.104' (x64)
.NET location: /usr/lib/dotnet

The following frameworks were found:
  9.0.4 at [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

I can see the equivalent of 'The following frameworks were found:' as 'The following locations were searched:'.

As part of implementing the configurable search options, I added a similar idea to our tracing when looking for hostfxr (our indication of whether .NET is installed) - for example:

The required library libhostfxr.so could not be found. Search location options [0xd]
  app-local: [/home/elinor/helloworld/bin/Debug/net10.0/]
  environment variable: [DOTNET_ROOT]
  global install location [/usr/lib/dotnet]
  self-registered config location [/etc/dotnet/install_location_x64]

We can maybe make that list a into nicer user-facing message.

The following locations were searched:
  Application directory: /home/elinor/helloworld/bin/Debug/net10.0/
  Environment variable: DOTNET_ROOT = <not set>
  Registered configuration: /etc/dotnet/install_location_x64 = <not set>
  Default location: /usr/lib/dotnet

[elinor-fung]

For the second case, the message is coming from the SDK. Anything that isn't a .dll/.exe gets passed to the SDK to handle.

Is this intended behavior? If the user passes a file but it's not a managed binary, we interpret it as a potential SDK command?

It is intended. If we can't run whatever argument as an app, we let the SDK try to handle it (SDK command, running a .NET tool). We could probably try to restrict it a bit so that we don't call the SDK and provide a specific error message if:

• the file that exists
• it is not a .dll or .exe
• the user-supplied argument has a directory separator (something like dotnet trace or dotnet build should still call the SDK if a file named trace or build exists).

[elinor-fung]

Split the existing file, non-dll/exe case into #116939 and renamed this one to be about including searched locations for .NET.