Make call-to-action host errors source-build friendly

[richlander]

Today, all of our host error messages send you to the Microsoft download site.

In some scenarios, that's both unfriendly and might not be the right end-user guidance. The solution is not immediately clear since the app may have been built with a Microsoft-built SDK and run on a Red Hat-built runtime (for example), while the host is a separate asset that doesn't change once built.

We should discuss this and see if there are options to explore. It is somewhat similar to dotnet/sdk#25935.

@elinor-fung @vitek-karas @distro-maintainers

[ghost]

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

Issue Details

---

Today, all of our host error messages send you to the Microsoft download site.

In some scenarios, that's both unfriendly and might not be the right end-user guidance. The solution is not immediately clear since the app may have been built with a Microsoft-built SDK and run on a Red Hat-built runtime (for example), while the host is a separate asset that doesn't change once built.

We should discuss this and see if there are options to explore. It is somewhat similar to dotnet/sdk#25935.

@elinor-fung @vitek-karas @distro-maintainers

Author:	richlander
Assignees:	-
Labels:	area-Host
Milestone:	-

[teo-tsirpanis]

@dotnet/distro-maintainers

[deeprobin]

Today, all of our host error messages send you to the Microsoft download site.

How about redirecting to GitHub (for non MSFT-builds)?

[vitek-karas]

I think it would make sense for the source build to be able to customize the link - so distro maintainer could decide where to point the URL. Just like distro maintainers effectively create their own RID and add it to the system.

(That is ignoring the technical side, I have no idea how to do that).

[mmitche]

I think it would make sense for the source build to be able to customize the link - so distro maintainer could decide where to point the URL. Just like distro maintainers effectively create their own RID and add it to the system.

(That is ignoring the technical side, I have no idea how to do that).

@vitek-karas There are currently conversations going on in https://github.com/dotnet/sdk/pull/25935/files#diff-9da24614831c308827a1ae533ffea392c97638c261dd42bd0f5226baa136d16eR24 around addition of an "OfficialBuilder" switch, which would be a way for organizations (including Microsoft) to add build logic specific to them in shared code.

[richlander]

How about redirecting to GitHub (for non MSFT-builds)?

That's actually not solving the primary problem. This isn't "non-MSFT" but "someone else". In the case, of Red Hat builds, it wouldn't serve any purpose to point to GitHub builds.

There is also the question of what should happen if someone just builds .NET from source (not Red Hat, but an arbitrary person). I'm not convinced that problem is worth solving.

I think it would make sense for the source build to be able to customize the link

Yes. That's what I'm thinking to.

@omajid I assume this is of interest to you. I'm guessing that your link would primarily link to documentation or do you have another idea in mind?

[tmds]

We could suggest the user to install the runtime/sdk package.
We have agreed on naming for these packages in https://docs.microsoft.com/en-us/dotnet/core/distribution-packaging.

[richlander]

Should we just create an alternative message for "package-style acquisition" and then figure out how to conditionalize it the best way?

[tmds]

Yes, we can print a message that requests the user to install the dotnet-sdk-x.y or dotnet-runtime-x.y package using the package manager.

[richlander]

I was just looking at this post: https://devblogs.microsoft.com/dotnet/dotnet-apphost-improvements/

There are a couple variations of the following message, but its good enough to just focus on this one:

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

App: C:\apps\helloworld\helloworld.exe
Architecture: x64
Framework: 'Microsoft.AspNetCore.App', version '7.0.0-preview.4.22251.1' (x64)
.NET location: C:\Program Files\dotnet

The following frameworks were found:
  5.0.17 at [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

Learn about framework resolution:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=7.0.0-preview.4.22251.1&arch=x64&rid=win10-x64

There are two MS links there. I'm going to ignore the help message but focus on the last one.

Here's a proposal on what it could say:

To install missing framework, install: dotnet-aspnet-7.0

The technical problem is that this message is in the apphost. For the most part, people are going to use the Microsoft-build apphost. It doesn't make sense from a customer standpoint to target a source-build apphost vs a Microsoft one to get this message, particularly related to portable Linux targeting. That doesn't suggest that there should be no source-build apphost but that's really unrelated.

That makes me think that the following message would be better, at least within the MS-built Linux apphost:

Install the following package (if available): 
dotnet-aspnet-7.0

Otherwise, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=7.0.0-preview.4.22251.1&arch=x64&rid=win10-x64

This approach would require a mapping between framework and package. That seems reasonable. Yes?

Source-build could omit the download link or not.

Good?

[vitek-karas]

This approach would require a mapping between framework and package.

This would have to be hardcoded in the apphost:

• Would only work for the frameworks which we knew about when releasing the apphost (if we or somebody else adds frameworks later on, this would not work)
• Can we confidently create the mapping? Meaning, are the package names the same across all Linux flavors/package managers?

Honestly the apphost is the least flexible component in the system - what if we simply change the wording to simply say something like "Go to this page: link" - and the web could provide the package mapping and so on. It's much easier to update the page.

On the other hand this might not be good enough for source build.

[jkotas]

For the most part, people are going to use the Microsoft-build apphost.

The people who are using the Microsoft-built apphost are likely going to run on Microsoft-built runtime.

I do not think it makes sense to optimize for mixing and matching bits from different .NET distros. It gets complex.

[richlander]

We could start by making this proposal source-build only.

A perfect scenario is global tools. That's where this experience would be useful.

[tryashtar]

Hi, I wanted to comment on #71993 / #3816, but those were both locked. Let me know if there is a better place.

I really don't like the experience of just dumping the user on a webpage. When my first experience with opening a program is that, I seriously question whether I even want to use the thing if I have to jump through hoops first.

If the program needs to download and install the runtime, it should ask you permission to do it itself.

As it stands, every user's first impression of .NET software is it assigning them homework. They have no idea what this website is, what all the different versions mean, why they can't just click yes and start their original program. I really love making things with .NET but my users are constantly asking me "so what's this thing it wants me to download?" and it's not leaving a very good first impression.

Thanks for all your work

[vitek-karas]

@tryashtar not sure which version you're using, we've made some improvements in this area relatively recently. The UI should be better (no fuzziness, nicer dialog, ...) and the website should now redirect directly to the correct download.

There are technical difficulties in adding the auto-install functionality - for one it's actually quite a lot of code to do that and every app would have to carry that code with it (so size is impacted).

Also - I don't think the app itself should act like an installer. The fact that .NET Framework apps behave this way is something which is intrinsic to .NET Framework being part of Windows - and it's discussed at length in #71993.

.NET 5+ offers two different ways to handle this:

• Build the app as framework dependent, but then the app has a prerequisite install. As with other things similar to this, it typically means the app should provide an install experience, and part of the install should be to make sure the machine has the required .NET runtime on it.
• Build the app as self-contained, in which case there should be no external dependencies and the app probably doesn't need an install experience (it may still need it for other reasons though)