Ambiguity with Action and Func parameter

Question

How is it possible that this code

TaskManager.RunSynchronously<MyObject>(fileMananager.BackupItems, package);

causes a compile error

The call is ambiguous between the following methods or properties:
'TaskManager.RunSynchronously<MyObject>(System.Action<MyObject>, MyObject)' and
'TaskManager.RunSynchronously<MyObject>(System.Func<MyObject, bool>, MyObject)'

when signature of the action is

public void BackupItems(MyObject package)

and "ambiguous" methods are

static class TaskManager
{
    public static void RunSynchronously<TInput>(Action<TInput> task, TInput param)
    {
        Task.Factory.StartNew(() => task(param));
    }

    public static bool RunSynchronously<TInput>(Func<TInput, bool> task, TInput param)
    {
        return Task.Factory.StartNew(() => task(param)).Result;
    }
}

It seems to me that there is an ample difference between these methods. What am I missing here?

EDIT:

Besides the accepted answer I just came across a solution in a similar question. Here is the link.

Answer 1

The reason is that the return type of a method is not part of its signature. Thus, while resolving the correct overload, the compiler only looks at the parameter of the method.

The easiest solution is to simply not use the implicit method group conversion. All of the following compile:

TaskManager.RunSynchronously<MyObject>(
    x => fileMananager.BackupItems(x), package);

TaskManager.RunSynchronously<MyObject>(
    (Action<MyObject>)fileMananager.BackupItems, package);

TaskManager.RunSynchronously<MyObject>(
    new Action<MyObject>(fileMananager.BackupItems), package);

The first one is the most elegant of them, but it also is the only one with a - slight - runtime performance impact, because of an additional redirection. However, this impact is so small that you actually shouldn't care.

Answer 2

I came across the same problem, the solution was:

var r = RunSynchronously<bool>(x =>
{
    return true;
}, true);

RunSynchronously<bool>(x =>
{
}, true);

Now, why the compiler cannot do that???

Answer 3

Another possible explanation for this nowadays is this:

The code was written for C# version 7.3 (used by default by MSBuild 16.x, corresponding to VS2019), but the build is attempted with an earlier version of C# (which is the default for MSBuild 15.x, corresponding to VS2017).

Earlier versions of C# throw this error, but the overload is resolved correctly in C# 7.3.