.NET Runtime missing prompt is not redirecting to the correct runtime URL

Symbai commented 4 years ago

Description

When the .NET Core Runtime is a missing you receive a messagebox where when the user agrees, it redirects the user to the download page where he can install it. Previously it has redirected the user to the correct runtime version. Now it redirects to https://dotnet.microsoft.com/download/dotnet-core/?utm_source=getdotnetcore&utm_medium=referral which is a collection of ALL runtimes, the end user will download the wrong version. The application will not launch and show the message again. We are currently receiving many support tickets because of this.

User sees this messagebox And gets redirect to this URL: And when he clicks on something, it gives them the SDK

Expectation

Because this is a (64bit) .NET Core 3.1 desktop application, it should redirect to https://dotnet.microsoft.com/download/dotnet-core/3.1/runtime/desktop/x64 OR at least to https://dotnet.microsoft.com/download/dotnet-core/3.1/runtime

Configuration

Published as .NET Core 3.1 Windows 10 (desktop application WPF or Winforms)

Host (useful for support):
  Version: 5.0.0-preview.3.20214.6
  Commit:  b037784658

.NET SDKs installed:
  3.1.201 [C:\Program Files\dotnet\sdk]
  3.1.202 [C:\Program Files\dotnet\sdk]
  3.1.300-preview-015135 [C:\Program Files\dotnet\sdk]
  5.0.100-preview.3.20216.6 [C:\Program Files\dotnet\sdk]

Regression?

Yes, it has worked before. I cannot say when it has stopped working, but it seems to be more a website redirect issue.

@vitek-karas @richlander Any update on this? Can we please get this fixed for .NET 6? Because on RC1 this issue still exist, the prompt clearly says what's missing: clicking on yes opens an URL which contains all the necessary information: https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=win10-x64&apphost_version=6.0.0-rc.1.21451.13&gui=true but user gets redirected to: https://dotnet.microsoft.com/download/dotnet/6.0/runtime?utm_source=getdotnetcore&utm_medium=referral Which offers ALL versions of .NET 6 (Console, Desktop Server) including x86 and Arm64. This is getting odd that this bug is not getting any attention for so long time.

dynamicons commented 2 years ago

Hello,

quick info from my side, have tested the Workflow again with a fresh installation of Windows 11 on Dell Inspiration (2016). on downloading Small Business Developments, a popup appears that reminds you just that .NET is missing. Then you are redirected to the .NET 5.0 selection page (so that works).

After installing .NET 5.0.12 Desktop Environment (x64) - where you have to know what you want as a New UseR - it tells you that the Microsoft.WindowsDesktop.App requires .NET 5.0.0 was not found. So the 2nd message is more detailed. However, it leads you to the same page - there again you have to know it's Windows 5.0 Desktop Environment. Clicking on the OK button again, it downloads 5.0.12 again. bummer. The standard user can not install Dynamic Applications, as a result.

From my perspective, with frequent versioning of .NET 5.0 Desktop Environment, no purpose to create a workaround self. There are many many developers affected, many many end users, and many many many people are so utterly poor, they can not afford large download quota. So the attempt to integrate everything into an all-in-one Setup is not appropriatet for Dynamic Applications, whereto we are bound by Law (AGB, Terms and Conditions vs UN 1948, declaration of Human Rights).

Thanks for prioritizing this,

Martin Bernhardt, geb. Grote. Founder www.dynamic-applications.org mbe@dynamic-applications.org

dynamicons commented 2 years ago

Hello .NET 5.0/6.0 Desktop Environment Support,

I think i've tracked down the problem to the file IoTDeveloper.runtimeconfig.json, which seems automatically created in parallel to IoTDeveloper.exe from .NET 5.0 Desktop release upon.

Here in the file it says version is "5.0.0" which then leads the .NET Desktop Environment resolver link algorithm to point to the latest version (5.0.12 or 5.0.13 or 5.0.14 now) to download, which is like a running target.

Then, the user can install 5.0.12 (x64), which he has to find out about and select kind of manually from all the choices given on the download Website shown.

But on next startup of the Windows 10 Store App, it again requests version 5.0.0 - bummer. So even the experienced user almost can not fix the problem, as .NET Desktop Runtime 5.0.0 seems no longer available.

So the version should rather be "5.0" in almost all cases. Then, the application should accept all minor 5.0.x revisions.

At the moment, the Programmer can not fix the problem, as we have no control about the 5.0.x release line detail revision. This is because the Programmer only selects .NET 5.0 Desktop as a release to compile against, right? - the rest is automatic and so the result handling must as well work automatically.

From my perspective, we can not expect from the Customer who is paying for a Professional Microsoft Store App to help themselves and doing a web search and so waste half an hour (minimum) on installing the basic requirements, manually.

This way we can expect angry customers who think the installation is already broken.

Worst start ever for a newly bought Windows 10 Store App. The Customer will naturally expect a fluent installation.

File IoTDeveloper.runtimeconfig.json as created from compiler:

{ "runtimeOptions": { "tfm": "net5.0", "framework": { "name": "Microsoft.WindowsDesktop.App", "version": "5.0.0" }, "configProperties": { "System.Reflection.Metadata.MetadataUpdater.IsSupported": false } } }

Thank you for prioritizing and resolving this issue, as soon as possible.

Martin Bernhardt, Founder www.dynamic-applications.org mbe@dynamic-applications.org

vitek-karas commented 2 years ago

But on next startup of the Windows 10 Store App, it again requests version 5.0.0 - bummer.

This is weird. The version 5.0.0 in the .runtimeconfig.json means 5.0.0 or higher (< 6.0.0). So if the user installs any .NET 5 on the machine, it should work. Is the architecture matching? (Installing x64 .NET 5 will not fix the problem if the app is x86).

EatonZ commented 2 years ago

Has this been looked at yet? On a current WinForms app, this is the URL that starts: https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=win10-x64&apphost_version=6.0.4&gui=true

That gets you redirected here: https://dotnet.microsoft.com/en-us/download/dotnet/6.0/runtime?cid=getdotnetcore

To improve the experience, the redirect should point here instead: https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-6.0.4-windows-x64-installer

...and here for x86: https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-6.0.4-windows-x86-installer

That leads the user to a direct download and makes it easier.

DevSelchow commented 2 years ago

Also it should be detected if the program requires ASP.NET. In that case it should redirect to the hosting bundle:
https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-aspnetcore-6.0.4-windows-hosting-bundle-installer

richlander commented 2 years ago

In the general case, the apphost version isn't that useful. It is just a bit of info that tells you the SDK version that the user used to build the app. We should still give you the latest 6.0.x version.

The key thing we should focus on is giving users a page focused on (in this example) a Windows x64 download.

/cc @mairaw

mairaw commented 2 years ago

I've assigned this to myself. This is a high-priority task for my team and we'll work on this as soon as we're done with some MAUI work.

richlander commented 2 years ago

Excellent. I'm happy to talk through ideas on how we might approach this UX.

agocke commented 2 years ago

@mairaw Any status update on this?

mairaw commented 2 years ago

Meeting with @richlander and @danzhu54 today to discuss this.

vitek-karas commented 2 years ago

Moving to 8 as there's no work on the runtime for 7, this is basically a tracking bug for the work on the website, which can happen at any time (not bound to the same release schedule as runtime repo).

DubbleClick commented 2 years ago

Wouldn't it be enough to simply fix the redirect on the website? It clearly already knows what version has to be downloaded, opens a link to it in the browser, but the website redirects to a page with all available .net downloads instead of just the one needed.

mairaw commented 2 years ago

Yes, that's what we're doing @DubbleClick and the work has already started now. So the fix should be coming soon.

mairaw commented 2 years ago

Hey folks! We pushed a fix for this to production this week and we're monitoring to see if we have any issues with any of the redirects. Please let me know if any redirect is not behaving as expected.

DubbleClick commented 2 years ago

Works great, thank you very much.

Edit: Nevermind, it only works great for the x64 version. If your application requires the x86 desktop runtime, it still downloads the x64 desktop one.

mairaw commented 2 years ago

Sorry to hear that @DubbleClick. Do you have the aka.ms link that is generated for that use case?

DubbleClick commented 2 years ago

https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x86&rid=win10-x86&apphost_version=6.0.8&gui=true

which redirects to

https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-6.0.10-windows-x64-installer?cid=getdotnetcore

mairaw commented 2 years ago

Thanks @DubbleClick. I looked at our telemetry and I figured out what was happening. We're pushing a fix in a few minutes.

It was checking the browser agent instead of respecting the arch being passed. We now have browser agent as a fallback, if needed.

agocke commented 1 year ago

I believe this is fixed. Closing out. Thanks @mairaw!

dotnet / runtime