Improve UI of error dialog for missing framework/runtime

[elinor-fung]

For 3.1, a basic error dialog was added to inform the user about a missing runtime/framework (#8222). In 5.0, we should investigate if we can make it nicer / more user-friendly through Win32 Task Dialogs.

See https://github.com/dotnet/core-setup/issues/8222#issuecomment-539669978

[EatonZ]

I have tested this feature in 3.1 and the message box directs to the page pictured below.

I think this should be presented better. If I were a novice computer user or someone in a hurry, I may accidentally download the wrong thing, like the .NET Framework runtime. I think the message box should direct users to a page that is more clear and provides a single, easy to see download button.
Or, alternatively, have the message box launch a direct link to download the installer in the browser.

Alternatively, just link to this page - I think it is better and more clear to people: https://dotnet.microsoft.com/download/dotnet-core/current/runtime

[vitek-karas]

@EatonZ this is still being worked on as per https://github.com/dotnet/core-setup/issues/8902. @rowanmiller @richlander may be able to provide more details.

[EatonZ]

@vitek-karas Thanks, looks like I'm not alone (:

[Symbai]

FYI: On improving the dialog in the future, the message on this dialog should also be improved as well. It should contain the exact version and bitness of the .NET Core that is missing. If somehow the message fails when a user clicks on "Yes" (see https://github.com/dotnet/core-setup/issues/8902#issuecomment-567844216) or this user decided to download it later / somehow else, he still might up ending picking the wrong version. Because currently the apphost knows what exactly is missing but don't tell it the user. And also because user may report issues to the developers about "Hey I got .NET Core installed but your app says its missing. Please fix" and it turns out he is missing a specific version.

Currently it only says:

"To run this application, you must install .NET Core. Would you like to download it now?"

Expected it to say in the future:

"To run this application, you must install .NET Core Desktop Runtime 3.1 (x64). Would you like to download it now?"

And to give it a more trustful experience maybe also (might be obsolete if the dialog becomes a task dialog and reveal its link like in https://github.com/dotnet/core-setup/issues/8222#issuecomment-539669978):

"To run this application, you must install .NET Core Desktop Runtime 3.1 (x64). Would you like to visit dotnet.microsoft.com and download it now ?"

[kpreisser]

Hi,

In 5.0, we should investigate if we can make it nicer / more user-friendly through Win32 Task Dialogs.

See https://github.com/dotnet/core-setup/issues/8222#issuecomment-539669978

It might be a bit "dirty", but would it be possible to use a manifest of an existing Windows binary, e.g. control.exe, to load common controls v6 and show the task dialog?
That file is available in the System32 directory (so it exists for each architecture including ARM64), and is available also e.g. on Windows Server 2008 R2 in "Server Core" mode where other GUI EXEs like explorer.exe or winver.exe are not available.

It contains a manifest resource (with ID 1) that includes a dependency on common controls v6 (this one is from the x86 variant):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Copyright (c) Microsoft Corporation -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    name="Microsoft.Windows.Shell.control"
    processorArchitecture="x86"
    version="5.1.0.0"
    type="win32"/>
<description>Windows Shell</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
        <requestedPrivileges>
            <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
        </requestedPrivileges>
    </security>
</trustInfo>
<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
        <dpiAware  xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    </windowsSettings>
</application>
</assembly>

The manifest could be used with the activation context APIs to load common controls v6 and then call TaskDialogIndirect, without the need to deploy an extra binary or to have any resources in the current apphost EXE.

For example, with a code like the following, showing the task dialog works for me without using an app.mainfest (note: I'm not a C++ programmer, so the code might look a bit ugly):

HRESULT TaskDialogIndirectWithControlExeManifest(_In_ const TASKDIALOGCONFIG* pTaskConfig, _Out_opt_ int* pnButton, _Out_opt_ int* pnRadioButton, _Out_opt_ BOOL* pfVerificationFlagChecked) {
    typedef HRESULT (WINAPI* PFN)(_In_ const TASKDIALOGCONFIG* pTaskConfig, _Out_opt_ int* pnButton, _Out_opt_ int* pnRadioButton, _Out_opt_ BOOL* pfVerificationFlagChecked);

    HMODULE hComctl = LoadLibraryExW(L"comctl32.dll", nullptr, LOAD_LIBRARY_SEARCH_SYSTEM32);
    PFN taskDialogIndirectPtr = (PFN)GetProcAddress(hComctl, "TaskDialogIndirect");

    if (taskDialogIndirectPtr != nullptr) {
        return taskDialogIndirectPtr(pTaskConfig, pnButton, pnRadioButton, pfVerificationFlagChecked);
    }
    else {
        // Try to use the manifest from control.exe to load common controls v6.
        ACTCTXW actCtx = { 0 };
        actCtx.cbSize = sizeof(ACTCTXW);
        // TODO: Get actual system directory with kernel32's GetSystemDirectoryW()
        actCtx.lpSource = L"C:\\Windows\\System32\\control.exe";
        actCtx.lpResourceName = MAKEINTRESOURCEW(1);
        actCtx.dwFlags = ACTCTX_FLAG_RESOURCE_NAME_VALID;

        // TODO: Call ReleaseActCtx() once the context is no longer needed
        HANDLE ctx = CreateActCtxW(&actCtx);
        if (ctx == INVALID_HANDLE_VALUE)
            return E_FAIL;

        ULONG_PTR cookie;
        if (ActivateActCtx(ctx, &cookie) == FALSE)
            return E_FAIL;

        // Try to get TaskDialogIndirect again.
        hComctl = LoadLibraryExW(L"comctl32.dll", nullptr, LOAD_LIBRARY_SEARCH_SYSTEM32);
        taskDialogIndirectPtr = (PFN)GetProcAddress(hComctl, "TaskDialogIndirect");

        HRESULT result;
        if (taskDialogIndirectPtr != nullptr)
            result = taskDialogIndirectPtr(pTaskConfig, pnButton, pnRadioButton, pfVerificationFlagChecked);
        else
            result = E_FAIL;

        DeactivateActCtx(0, cookie);

        return result;
    }
}

A downside is that this would rely on control.exe being present and embedding a manifest (with resource ID 1) that uses common controls v6, but there could be a fallback to MessageBox if TaskDialogIndirect is still not available for some reason.
(Additionally, I think many other components already depend on control.exe being present (for example, sconfig.vbs uses control timedate.cpl to show the date/time settings, and there is control userpasswords2 etc.), so I think it is safe to assume control.exe won't go away for a long enough time.)

[vitek-karas]

Thanks a lot for the suggestion. I think this could be made to work even without the dependency on control.exe. I tried a simple console app which had no default manifest:

• By default the task dialog can't be imported and it doesn't work (as expected)
• I added an RT_MANIFEST resource with ID 101 with the necessary assembly dependency to Common-Controls
• I tried again without any special code- still doesn't work - this is important, adding a "random" manifest resource does not enforce a manifest on the app
• I then added the code you have above pointing to the exe of the app itself and loading resource id 101 and now the dialog works

So the solution might be to add a custom manifest resource to apphost with some "weird" ID (probably even a string and not a number) which would enable Common-Controls. This in itself should not have any effect on apps as Windows doesn't seem to load that manifest if none other is available. I also tried adding a normal manifest to the app - that one is picked up over the hidden one. And then use the code above to activate that manifest for the duration of the call to TaskDialog. We will have to test how big is the size impact of such change (apphost.exe is very size sensitive), but it looks promising.

[199621616]

验证正确，远比提示更重要。在.NetCore3.1WinForm应用中，频繁出现此提示，然而它验证又不正确。导致许多最终用户被迫中止使用。这个问题，很严重。
并且，它还经常的发生。还有的时候发生，一台电脑上的两个应用，一个应用出现此提示，而另一个应用则可正常使用。
最好3.1就能改掉它。损伤太大！！！

好多天以前，我就提出了这个问题。似乎它应该从这里提交更合适
dotnet/winforms#3028

Verification is more important than prompt. In the application of. Netcore3.1 WinForm, this prompt appears constantly, but its verification is not correct. As a result, many end users were forced to suspend their use. This problem is very serious. And

It also happens frequently. There are also times when two applications on one computer appear this prompt, and the other can be used normally.

3.1 is the best way to get rid of it. Damage is too big!!!

I asked this question many days ago. It seems more appropriate that it should be submitted from here

[vitek-karas]

@199621616 Thanks for the report, but it's really hard to tell what's wrong. Per the issue in winforms you have a single-file application. Is it also self-contained? (Easiest way to tell is by size, self-contained apps will be much larger - cca 70-100 MB). How do you build/publish the app (the command line and any publish related settings in the project file would help).

We haven't seen reports like yours yet (where it would work and then suddenly stop working). If you can get this to repro, can you please try this from a command line (on a machine where it fails):

set COREHOST_TRACE=1
set COREHOST_TRACEFILE=host_trace.txt
<run the application>

This should produce the file host_trace.txt which will contained detailed information about what the application tried to do and why it failed. Please note that the file contains information about the machine, potentially the user running it and some local paths and names. If you're comfortable please share this file with us. If not, you can try to see what's wrong by looking into the file.

[199621616]

@vitek-karas 感谢这么快看到的回复。因为这个提示的出现过于频繁，并且一旦出现最终用户就不能继续使用，我们已调整部署模式，由原来的框架依赖调整为独立。这样调整后未见反映出现此提示，但是出现了新的问题，就是刚刚部署完成时应用可以正常使用，但不知道会在什么情况下出现双击桌面图标应用不启动，无任何反映。只能重新安装新的安装包才可以使用应用。
两种部署模式，都是生成单个文件。我们会记录下你所说的这个生成host_trace.txt报告的方式，但这需要修改部署模式再部署到用户使用环境中再出现此情况时，才可能得到它。需要多长时间才能得到它我们不确定。

@vitek Karas thanks for the quick response. Because this prompt appears too frequently, and once it appears, the end user cannot continue to use it. We have adjusted the deployment mode from the original framework dependency to independence. After such adjustment, this prompt does not appear, but there is a new problem, that is, when the deployment is just completed, the application can be used normally, but under what circumstances, the double-click desktop icon application will not start without any reflection. The app can only be used by reinstalling a new installation package.

Both deployment modes generate a single file. We will record what you said about how to generate the host_trace.txt report, but we need to modify the deployment mode and deploy it to the user's environment before we can get it. We're not sure how long it will take to get it.

项目情况及依赖项：

原来的发布方式：

调整后的发布方式：

[199621616]

@vitek卡拉斯 你好，我们重新改用框架依赖部署模式后今天有用户反映再次出现找不到.NetCore3.1提示。我们远程连接到客户电脑分别执行了set COREHOST_TRACE=1和
set COREHOST_TRACEFILE=host_trace.txt。执行后再次启动应用，没有找到host_trace.txt文件。
改用管理员身份执行这两个命令，也没有生成此文件。
我们改用新版本（同样是框架依赖、生成单个文件），可以正常启动

Hello, we changed to framework dependency deployment mode again. Today, some users reported that they could not find. NETCORE 3.1 again. We remotely connected to the client computer and executed set corehost ﹐ trace = 1 and
set COREHOST_TRACEFILE=host_trace.txt。 Start the application again after execution. The file host_trace.txt was not found.
The two commands were executed as administrators instead, and the file was not generated.
We use the new version (also framework dependency, single file generation), which can be started normally

[vitek-karas]

Maybe I should have been clearer, the env. variable setting and running the app must happen from the same command line window, so that the env. variables are seen by the application. The file will be created in the "current directory" as seen by the application when started. So assuming your application lives in C:\MyApp\myapp.exe opening a command line (no need for admin) and running:

cd C:\Temp
set COREHOST_TRACE=1
set COREHOST_TRACEFILE=host_trace.txt
C:\MyApp\myapp.exe

This should produce C:\Temp\host_trace.txt.

[199621616]

收到一个host_trace.txt文件：
host_trace.txt

[199621616]

@vitek-karas The installation path and name of this application are:：C:\Program Fiels (x86)\聊城市泽方软件开发有限公司\住院护士工作站\标准版.住院护士工作站31.exe。

[elinor-fung]

@199621616 I suspect you may be hitting #3778. That should have been addressed in the .NET Core 3.1.4 release; I would suggest upgrading to that version re-building/publishing.

[199621616]

Thanks

[199621616]

host_trace.txt
今天在.NetCore3.1.7环境中，再次出现此情况

[199621616]

编译环境、运行环境都是.NetCore3.1.7，可是host_trace.txt中的3.1.2从何而来？

[EatonZ]

@agocke I see you moved this to 6.0. Does that mean .NET 5 will not feature any changes or improvements to this dialog?

[agocke]

Probably not. Unfortunately we didn't have time to make significant improvements here and the bar for making changes is very high right now.

[AnakinRaW]

I recently observed similar UX issues. While the download button in the dialg points you to the correct site it lacks giving you the infomration which architecture of the runtime you need to install (x64, x86 or ARM).

In the long term however i think it would be best for end-users when the x64 runtime is capable of running x86 compiled apps as well. I guess the other way around is impossible but that should'nt be any real world issue anyway nowdays.

My scenario is a WPF (single file; framework-dependant) app targeting win-x86 running on Windows 10 x64 with no .NET installed. After installing .NET 5 x64 the app still wouldn't run bus showed the download dialog again.

For end-users that would be a very frustrating experience.

[richlander]

Shouldn't we move this to 7.0 at this point?

[Symbai]

Shouldn't we move this to 7.0 at this point?

I'm sorry but you cannot be serious... This is an issue since .NET 3.1 released in 2019. First post says it should be checked in .NET5, then in .NET6 and now you ask to target this in .NET7 instead.

I wouldn't actually mind you delay the "making the error box look nicer" but that the messagebox still nagivates to a website with several download buttons leaving it to a customer to choose the correct one is absolutely a big issue. It should navigate the user directly to the exact download page of the exact runtime it needs.

Because of this problem many developers ship their product self contained wherever its possible but sadly that is not always possible and when it isn't possible it cost a huge amount of man power on support. Because customers aren't developers and they aren't reading, they always download the wrong runtime.

The navigation should be fixed in .NET6 and you should consider back porting this to .NET 3.1 because it has LTS until end of 2022. There is absolutely no argument why this should take another year (and maybe even more).

[EatonZ]

I do not agree with moving to 7.0.
Considering 6.0 is LTS and will be around for a while, it's important to have improvements in this area to improve our customers' experience.
@Symbai I think backporting to 3.1 is probably unreasonable since only major issues are addressed in servicing releases.

[agocke]

This issue is now mainly tracking the improvements to the dialog box appearance. Improving the message is tracked by #3816 and we've already merged a PR (#57089) to include the exact runtime version and architecture needed by the application.

I'll see what we can do about the website.

[elinor-fung]

I believe there is #3811 for the message and #36765 (tracking an issue on a private repo) for the website.

[richlander]

Could we target this change at 6.0.200? I'm not sure if we've made apphost changes in servicing before, but it seems reasonable to me.

[AnakinRaW]

i also don't think scheduling this to 7.0 is a good idea. For someone who writes software for end-users (possibly teenagers who don't know much about their systems, let alone .NET) this is a miserable situation. It's one of the big reasons why I haven't moved most of my tools to .NET yet and still sticking with .NET Framework because I don't want to give that kind of support multiple times a day and avoid frustration not beeing able to even run the application.

[agocke]

If this issue is only targeting improving the window-chrome, it does not seem like that would meet a servicing bar.

[Symbai]

That is something I can agree with because it's not a bug and I have to admit that making something more beautiful hasn't much weight of priority. But what about fixing the URL redirection which is obviously a bug since it has worked before. There is no status update since November 2020 and people say issue is tracked on a private repo where I don't have any access to. Can someone with access please take a look and make sure this is getting fixed for .NET 6 and .NET 3.1?

[agocke]

@richlander has been triaging the website bug and trying to find resources to work on it

[Symbai]

The issue is still not fixed, users get console / desktop / server downloads including x86, x64 and arm64 downloads to choose from, what a nightmare: #36765 (comment) isn't there anyone else than richlander who can fix this redirection bug?

[agocke]

Still working on it, haven't found the right person yet

[EatonZ]

Why not update to use the direct aka.ms link?

Example: https://aka.ms/dotnet/5.0/windowsdesktop-runtime-win-x64.exe

Replace "5.0" and "x64" where needed.
This link generated a direct download link without any landing page confusion.

[agocke]

Some of this logic is built-in to the apphost, which ships in customer apps -- so we can't update that. Fixing the redirects and webpages fixes the problem for everyone, including down-targeting apps. The runtime is also shut down for everything but the most severe bugs for 6.0. We're effectively in servicing.

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

PS. i would recommend to introduce a .NET Desktop Environment Service Tag with AppManifest.xml for a quick fix.

So that shifts the workload of defining the correct version down to each developer (can be documented as such - temporary solution).

The current half-automatic algorithm can still be further elaborated, and at a later point in time, the AppManifest.xml service tag can be deprecated again. In theory, the system should be able to identify the correct version of a .NET Framework and a .NET Core App as required. There's not so much of a difference between 5.0.0 and 5.0.12 from the probability of running app at all perspective. Just a thought, because i am waiting for a solution for more than a year now (.NET 5.0 Release - early reporter).

That's inacceptable for any serious business man. Thank you. -- Martin

Martin Bernhardt, Founder
www.dynamic-applications.org

[dynamicons]

Hello .NET 5.0/6.0 Desktop Runtime 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 algorithm to point
to the latest version (5.0.12 or 5.0.13 or 5.0.14 now), 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.

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.

The Customer will naturally expect a fluent installation. At the moment, the Programmer can not fix the problem, either, as we also have no control about the 5.0.x release lines. 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.

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
}
}
}

[EatonZ]

Hi team,

.NET 7 is well in development now. What improvements can we realistically expect here to make it for .NET 7 later this year?
Has the Task Dialog idea been completely ruled out? If so, what other ideas are being considered?

[vitek-karas]

Currently this is on the list of potential improvements. We've recently improved the wording on the existing dialog and that should hopefully help a little bit: #67564 and #67022.

But I want to set the right expectations: It's likely that this experience will always be relatively simplistic (nicer dialog doesn't solve the complexity of the problem, which doesn't mean that it's bad to have a nicer dialog).

Anything which would actually provide a good UX is lot more complicated and ventures into the space of installers/setup. I don't think the runtime (and especially not such a core low-level component as the apphost) should try to solve problems in the installers/setup space. There's an inherent downside to doing that - the apphost is part of every single .NET application, we need to be careful about adding more into it as it will at the very least increase the size of the application... every application. Another downside is that apphost is not servicable, so future versions of .NET still have to consider all features of old apphosts. So the more logic there's in it, the more likely it is that such logic will become stale/wrong in the future without any real way of fixing that. This is one of the reasons why most of the responsibility is shifted to the web site (which admittedly could to a much better job).

[richlander]

I think we should focus on fundamental scenarios (as we have been) and not invest in a nicer dialog. The dialog is important but it doesn't need to look pretty. I agree with the other things Vitek said, too.

I propose we close this issue and (if folks want) create new ones on specific challenges, but not about creating a nicer dialog.

[Symbai]

The dialog is important but it doesn't need to look pretty

We speak about END USER experience here, not about developer experience. For devs it doesn't have to be shiny but for end users its just bad experience if they'll get a Windows XP error dialog in the year of 2022.

And regarding the size I think you guys should rather make sure that everything .NET supports gets support for trimming feature. For example you left WPF and Winforms (both products of MICROSOFT) completely out but they are No. 1 for desktop development. If you speak about saving ~100kb on apphost, then I speak about saving ~70mb for WPF and Winforms. At least for WPF there is absolutely no activity and no sign for future activity from the WPF owners regarding trimming and community PR's trying to make WPF trimable are left unreviewed for months now. So there is a lot more potential to save space than this one.

I cannot speak about complexity. But the apphost aka executable, isn't that only used on Windows machines? I doubt that we will run into problems in the future if we simply use Windows APIs. Even >10 years old obsolete Windows APIs haven't been removed to ensure compatibility.

[richlander]

That's a good point, but what I said still stands. Making error dialogs pretty isn't a priority for us, for any user. Ideally, no-one ever sees them. We have more significant issues to resolve. For example, I'm asking the team to fix our RID catalog problem, which requires much of the resolution in the host.

The trimming is a good point. Unfortunately, there are mountains standing in our way of resolving trimming for WPF. I don't think it will ever happen. The challenges relate to WPF using MC++ and that we cannot reliably reason about IL/.NET roots via XAML.

I know you are disappointed. I'm trying to be very transparent and direct.

[Symbai]

Unfortunately, there are mountains standing in our way of resolving trimming for WPF

It would help if the repo owners would review the PRs of the community trying to help with that, like this one for example: dotnet/wpf#6171 but they are completely ignored, even the PR owner has asked for the WPF team for giving a feedback but hasn't received an answer like as nobody feels responsible or "knowledged-enough" to reply. And this isn't the only example, there were also now 3 community attempts to bring a basic folder picker to WPF, the last one is a 2 or 3 liner, still being ignored by WPF repo owners. I dont know the reason, it can be that WPF team has no clue about WPF (which is a questionable decision that they have taken it over then) or they have to little resources (although they claim they have 3 full working days to deal with issues and PRs which in reality never happens) but then go and hire someone. This is still a very popular framework and as long as WinUI and MAUI stuck with very basic problems, like setting a window title name crashes the application, it is not a replacement in the foreseeable future.

Back to the apphost error dialog. I understand that its low priority and I don't ask to change that. But you would be surprised to know how many end users are seeing this dialog on a daily base and how much support developers are wasting on this issue. Especially because it still redirects not the exact runtime it needs. And for this reason many devs try to publish as self contained or using AOT but guess what, here we go again with WPF and Winforms: Self contained is ~140mb and AOT is not supported. At least the Winforms team is actively working on it unlike the WPF team.

Yes I am disappointed and I respect you are transparent and direct, so I am. If my words doesn't make you think about it again so it be. But at least I've tried it.

[richlander]

That WPF PR is a good example. Yes, it is in the direction of helping with the trimming problem and is probably generally a good idea. I'd also like to see faster traction on WPF issues so that PRs like that one get merged.

it can be that WPF team has no clue about WPF.

Please keep the conversation civil.

But you would be surprised to know how many end users are seeing this dialog on a daily base and how much support developers are wasting on this issue.

Not really surprised. We have the same dialog for .NET Framework and the traffic for both hit a webserver on a specific link. It's pretty straightforward to measure (and we do). Ideally, people don't see this dialog, but they do.

On that note, we put a fair bit of effort into improving this dialog and others in .NET 7 to make the information more helpful for end users and to make the information more useful for support teams. I'll probably do a write-up on that to pull together the changes into one place and make it easier to give feedback on how we could improve the experience more.

The links do go to a version-specific page on the website, but not to an OS-specific one. We're still working on that. I hope that gets resolved soon. @mairaw is working on it.

[Symbai]

Please keep the conversation civil.

I clearly didn't wanted to sound disrespectful. As far as I know the original WPF developers no longer working on it but instead the WinUI team took it over. WinUI is written in C++ mostly, what I meant is that the current repo owners maybe have difficulties to understand which change is safe and which may alter the behavior since they 1) Have to understand the complexity of WPF and 2) understand C#.

If I am right it pretty clear why "complex" PR's are being ignored. They probably rely on bringing up the automated test environment to get an idea, whether its safe to merge a PR or not. Yet again, I still believe, IF I AM CORRECT, it was the wrong decision. Not only that WinUI has enough problems to solve own its own, WPF is too popular to put it into this "low priority" position.

[richlander]

I'm not going to discuss team skill-sets.

I get your concern, but we've gotten well off of the key topic. I'm going to close this issue now.

We're declining the request (this issue) to improve the fundamental UI of the dialog.

We are going to fix the website, tracked by #36765.

We are welcome to other ideas on how to improve the experience of missing runtime components.