Bug: Ambiguous reference for winrt::Microsoft::Windows::ApplicationModel.Background::UniversalBGTask::Task::Run

[dlech]

Version

2.0.240111.5

Summary

I have a feeling that this is perhaps an API bug, but CppWinRT could be made to work around it. A new class added in Windows App SDK 1.7 has an explicit interface implementation (in C# terms) that isn't seen in other APIs and doesn't seem to follow the WinRT type system guidelines.

This causes CppWinRT to generate multiple Run methods. One for the public interface and another for the explicit interface implementation that should actually be private and therefore not projected.

https://learn.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/microsoft.windows.applicationmodel.background.universalbgtask.task?view=windows-app-sdk-1.7

Reproducible example

It will take some time to make a minimal test case.

Expected behavior

CppWinRT should not generate ambiguous methods.

Actual behavior

Code fails to compile with error.

Additional comments

Here is the actual compiler error.

C:\Users\extra\work\pywinrt\projection\winui3\winui3-Microsoft.Windows.ApplicationModel.Background.Univer
salBGTask\py.Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.cpp(71,31): error C2668: 'winr 
t::impl::consume_Windows_ApplicationModel_Background_IBackgroundTask<D>::Run': ambiguous call to overload
ed function [C:\Users\extra\work\pywinrt\_build\release\_winui3_microsoft_windows_applicationmodel_backgr 
ound_universalbgtask.vcxproj]
C:\Users\extra\work\pywinrt\projection\winui3\winui3-Microsoft.Windows.ApplicationModel.Background.Univer
salBGTask\py.Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.cpp(71,31): error C2668:       
   with [C:\Users\extra\work\pywinrt\_build\release\_winui3_microsoft_windows_applicationmodel_background
_universalbgtask.vcxproj]
C:\Users\extra\work\pywinrt\projection\winui3\winui3-Microsoft.Windows.ApplicationModel.Background.Univer 
salBGTask\py.Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.cpp(71,31): error C2668:       
   [ [C:\Users\extra\work\pywinrt\_build\release\_winui3_microsoft_windows_applicationmodel_background_un
iversalbgtask.vcxproj]
C:\Users\extra\work\pywinrt\projection\winui3\winui3-Microsoft.Windows.ApplicationModel.Background.Univer 
salBGTask\py.Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.cpp(71,31): error C2668:      
       D=winrt::Microsoft::Windows::ApplicationModel::Background::UniversalBGTask::Task [C:\Users\extra\w 
ork\pywinrt\_build\release\_winui3_microsoft_windows_applicationmodel_background_universalbgtask.vcxproj]
C:\Users\extra\work\pywinrt\projection\winui3\winui3-Microsoft.Windows.ApplicationModel.Background.Univer 
salBGTask\py.Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.cpp(71,31): error C2668:       
   ] [C:\Users\extra\work\pywinrt\_build\release\_winui3_microsoft_windows_applicationmodel_background_un 
iversalbgtask.vcxproj]

[dlech]

These are the two generated methods that are ambiguous:

Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.h

    template <typename D> auto consume_Microsoft_Windows_ApplicationModel_Background_UniversalBGTask_ITask<D>::Run(winrt::Windows::ApplicationModel::Background::IBackgroundTaskInstance const& taskInstance) const
    {
        check_hresult(WINRT_IMPL_SHIM(winrt::Microsoft::Windows::ApplicationModel::Background::UniversalBGTask::ITask)->Run(*(void**)(&taskInstance)));
    }

Windows.ApplicationModel.Background.h

    template <typename D> auto consume_Windows_ApplicationModel_Background_IBackgroundTask<D>::Run(winrt::Windows::ApplicationModel::Background::IBackgroundTaskInstance const& taskInstance) const
    {
        check_hresult(WINRT_IMPL_SHIM(winrt::Windows::ApplicationModel::Background::IBackgroundTask)->Run(*(void**)(&taskInstance)));
    }

[godlytalias]

There are some cppwinrt based samples on the usage of these APIs here, https://github.com/microsoft/WindowsAppSDK-Samples/tree/release/experimental/Samples/BackgroundTask

Are you following the same pattern here? Or anything is different?!

[dlech]

It looks like in the examples that BackgroundTask is being subclassed and an the Run method is overridden. This bug would only happen if someone tried to call Run.

I'm using the PyWinRT code generator to create a projection for the Windows App SDK. It just automatically creates code to call every possible method even if it doesn't make sense that anyone would ever call it.

[godlytalias]

I see, Ideally a background task implementation would not require to call Run directly, application just have to override the Run method as in sample and it gets triggered internally when background task executes.

[sylveon]

Here's a minimal repro:

#include <winrt/Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.h>

void test(const winrt::Microsoft::Windows::ApplicationModel::Background::UniversalBGTask::Task& task)
{
    task.Run(nullptr);
}

The error is correct. The Task class inherits both ITask and IBackgroundTask, both of which have a Run(IBackgroundTaskInstance) method (this can be observed by looking at the WinMD). CsWinRT fails to generate an interop assembly for this namespace too with pretty much the same reason. As far as I know, this is pretty much an invalid WinRT class definition (two methods should generally not share names).

The issue stems from the IDL: https://github.com/microsoft/WindowsAppSDK/blob/e8d5edff29c744191833931cab2fd65c6b07b0b2/dev/WindowsAppRuntime_UniversalBGTaskDLL/Task.idl#L14

For some reason, it redeclares the Run method when it shouldn't. You don't have to redeclare the methods of interfaces that you're overriding. The correct thing to do here would be to remove the Run method from this runtimeclass. This is technically ABI breaking, but this component isn't meant to be consumed (otherwise this mistake would've been spotted way earlier), so I think it's fine.

[sylveon]

Directly filed microsoft/WindowsAppSDK#5313 in WASDK to solve this issue.

[github-actions]

This issue is stale because it has been open 10 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[dlech]

I think we all agree this is an API bug and nothing to do here, so closing.

[sylveon]

Upstream PR got merged! Should show up in an update to WASDK in the future.