Calls to comctl32.dll succeed in .NET 4.8, but fail in .NET 5 with System.EntryPointNotFoundException

• .NET Core Version: 5.0.100 and 3.1.404
• Windows version: Windows 10 (18363.1139)
• Does the bug reproduce also in WPF for .NET Framework 4.8?: No
• Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc…)? No

Problem description:

Calls to comctl32.dll succeed in .NET Framework 4.8, but fail in .NET 5 and also in .NET Core 3.1 with a System.EntryPointNotFoundException.

e.g.

[DllImport("comctl32.dll", PreserveSig = false)]
private static extern void TaskDialogIndirect([In] ref TaskDialogConfig pTaskConfig, out int pnButton,
    out int pnRadioButton, [MarshalAs(UnmanagedType.Bool)] out bool pfVerificationFlagChecked);

// ...

var config = new TaskDialogConfig
{
    pszWindowTitle = "Task dialog title",
    pszMainInstruction = "Task dialog main instruction",
    dwCommonButtons = TaskDialogCommonButtonFlags.OkButton | TaskDialogCommonButtonFlags.CancelButton,
    // ...
};

using (new ComCtlv6ActivationContext(enable: true))
{
    TaskDialogIndirect(ref config, out _, out _, out _);
}

Actual behavior:

System.EntryPointNotFoundException: Unable to find an entry point named 'TaskDialogIndirect' in DLL 'comctl32.dll'.
   at TaskDialogApi.TaskDialog.TaskDialogIndirect(TaskDialogConfig& pTaskConfig, Int32& pnButton, Int32& pnRadioButton, Boolean& pfVerificationFlagChecked)

Expected behavior:

Display the Task Dialog requested

Minimal repro:

• repro-wpf-net5-comctl32-entrypointnotfoundexception

[vitek-karas]

I have no idea who added the manifest in .NET Framework, I just want to clarify that the fact that it lives next to mscorlib is probably not very telling. There are more than 400 files next to mscorlib in .NET Framework…

That said I think this is something which should ideally work “seamlessly” whenever “Windows Dektop” is asked for. For example, it might make sense to automatically include this in the application manifest for any app which targets net5-windows (or net6-windows).

[vitek-karas]

Well - it’s already in runtime repo right now 😉 Depending on the design it might not belong there. For example if we were to implement the solution where windows apps get different manifest by default, it would probably belong to the SDK repo.

But I think there’s a discussion to have:

• We want to preserve backward compat with .NET Framework -> we would have to include XPTheme.manifest in the shared framework (next to coreclr.dll and other “root” assemblies). This doesn’t feel right to be honest, since we would have to do this for all apps, not just net5-windows apps - any app on windows regardless of its purpose would get that file.
• We want to fix the experience for new apps -> we can tie it to the TFM and make SDK use different default manifest based on the TFM (net5 -> no change, net5-windows -> the new manifest) - but there are probably other similar solutions.