Assign async lambda method to variable typed as a Task in C# and VB.NET

When I first read the title of your question I thought "Eh? Who would propose trying to assign a value of type x to variable of type y, not in an inheritance relationship with x? That's like trying to assign an int to a string..."

I read the code, and that changed to "OK, this isn't assigning a delegate to a Task, this is just creating a Task and storing it in a collection of Tasks.. But it does look like they're assigning a delegate to a Task...

Then I saw

Note my technique of invoking the lambda method immediately via the () after the the lambda block is closed {}. This ensures a Task is returned, not a Func.

The fact that you have to explain this with commentary means it's a code smell and the wrong thing to do. Your code has gone from being readably self documenting, to a code golf exercise, using an arcane syntax trick of declaring a delegate and immediately executing it to create a Task. That's what we have Task.Run/TaskFactory.StartNew for, and it's what all the TAP code I've seen does when it wants a Task

You'll note that this form works and doesn't produce an error:

HashSet<Task<(string Value, int ToNodeId)>> regionTasks =
  new HashSet<Task<(string Value, int ToNodeId)>>();
foreach (Connection connection in Connections[RegionName])
{
    regionTasks.Add(Task.Run(async () =>
    {        
        string value = await connection.GetValueAsync(Key);
        return (value, connection.ToNode.Id);
    }));
}

It is far more clear how it works and the 7 characters you saved in not typing Task.Run means you don't have to write a 50+ character comment explaining why something that looks like a delegate can be assigned to a variable of type Task

I'd say the C# compiler was saving you from writing bad code here, and it's another case of the VB compiler letting developers play fast an loose and writing hard to understand code

An easy way to invoke asynchronous lambdas in order to get the materialized tasks, is to use a helper function like the Run below:

public static Task Run(Func<Task> action) => action();
public static Task<TResult> Run<TResult>(Func<Task<TResult>> action) => action();

Usage example:

regionTasks.Add(Run(async () =>
{
    string value = await connection.GetValueAsync(Key);
    return (value, connection.ToNode.Id);
}));

The Run is similar with the Task.Run, with the difference that the action is invoked synchronously on the current thread, instead of being offloaded to the ThreadPool. Another difference is that an exception thrown directly by the action will be rethrown synchronously, instead of being wrapped in the resulting Task. It is assumed that the action will be an inline async lambda, as in the above usage example, which does this wrapping anyway, so adding another wrapper would be overkill. In case you want to eliminate this difference, and make it more similar with the Task.Run, you could use the Task constructor, and the RunSynchronously and Unwrap methods, as shown below:

public static Task Run(Func<Task> action)
{
    Task<Task> taskTask = new(action, TaskCreationOptions.DenyChildAttach);
    taskTask.RunSynchronously(TaskScheduler.Default);
    return taskTask.Unwrap();
}
public static Task<TResult> Run<TResult>(Func<Task<TResult>> action)
{
    Task<Task<TResult>> taskTask = new(action, TaskCreationOptions.DenyChildAttach);
    taskTask.RunSynchronously(TaskScheduler.Default);
    return taskTask.Unwrap();
}