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

[Symbai]

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.

Related

#3848

ping: @dagood @richlander @vitek-karas

[ghost]

Tagging subscribers to this area: @vitek-karas, @swaroop-sridhar
Notify danmosemsft if you want to be subscribed.

[vitek-karas]

It works for missing framework error which leads to URL like this:

https://aka.ms/dotnet-core-applaunch?arch=x64&rid=win10-x64&gui=true&apphost_version=3.1.0&framework=Microsoft.NETCore.App&framework_version=3.1.0

This does redirect to https://dotnet.microsoft.com/download/dotnet-core/3.1/runtime/ as expected.

But the one where the runtime is missing all-up doesn't work. The URL looks like this:

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

And that leads to https://dotnet.microsoft.com/download/dotnet-core.

[richlander]

This is up to me to fix. I'll look at it. I had noticed the same thing, but hadn't fixed it yet.

[vitek-karas]

This should be handled by the web site: https://github.com/dotnet/website/issues/1958

[Symbai]

The link you provided gives me a 404 error page. Probably because the repo is private?! How can I track the issue and get notified when its fixed then?

[vitek-karas]

Sorry - I didn't realize it's private. I'll keep this issue opened for tracking purposes.

[Symbai]

Hi, can you give us any update on this? It seems like this is still not fixed for .NET 5: #3816 (comment)

[vitek-karas]

Thanks for the reminder - I'll ping the right people again.

[Symbai]

@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]

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]

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]

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]

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]

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]

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]

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]

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

[agocke]

@mairaw Any status update on this?

[mairaw]

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

[vitek-karas]

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]

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]

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

[mairaw]

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]

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]

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

[DubbleClick]

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]

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]

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