Blazor webasm - EventCallBack with async handler show compiler error CS0407 or CS0123

[LaughingJohn]

Hi,

I have a component with an EventCallBack which has a signature of:

[Parameter] public EventCallback<MouseEventArgs> OnClick { get; set; }

When I add an async event handler:

<ToolbarButton OnClick="@CopyCompanyAddress"
                          Label="Copy Company Address"
                          SvgFolder="SvgFolder.Buttons"
                          SvgName="copycompanyaddress" />

Where the handler looks like this:

private async Task CopyCompanyAddress(MouseEventArgs args)

I get an error message and squiggly telling me this:

Error CS0123 No overload for 'CopyCompanyAddress' matches delegate 'Action'

If I change the handler to remove the the MouseEventArgs (which I don't actually need) like this:

private async Task CopyCompanyAddress()

I get the following error message:

Error CS0407 'Task FmFormItem.CopyCompanyAddress()' has the wrong return type

I was under the impression it was OK to add a Task async handler for EventCallBack? Non-async void handlers don't show these errors, nor does using async void.

I'm using VS2019 16.9 preview 1. Everything appears to compile and run, but the error message is making me nervous. Am I doing something wrong or is the error just misleading?

Thanks.

[javiercn]

@LaughingJohn thanks for contacting us.

Does it build without errors from the command-line? It might be a tooling issue.

To answer your question, you aren't doing anything wrong and it should work without issues.

[LaughingJohn]

Hi @javiercn,

I'm not much of a command line user, but I ran dotnet build --no-incremental and it seems to build OK. If what I'm doing is OK, then it must be the tooling as you say.

Thank you for you help! LJ

[javiercn]

@LaughingJohn thanks for the additional details. It might be that the tooling got out of sync.

@NTaylorMullen can you take it from here?

[ghost]

Thanks for contacting us. We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[captainsafia]

@NTaylorMullen Can you clarify why you think this is a compiler bug?

[NTaylorMullen]

@NTaylorMullen Can you clarify why you think this is a compiler bug?

yup definitely compiler

[TanayParikh]

@NTaylorMullen Can you clarify why you think this is a compiler bug?

yup definitely compiler

I'm not much of a command line user, but I ran dotnet build --no-incremental and it seems to build OK. If what I'm doing is OK, then it must be the tooling as you say.

Seems like its fine in CLI but not in VS. Would this not fall under the tooling umbrella? @NTaylorMullen

[TanayParikh]

Granted tooling doesn't "make up" the diagnostics, so it must be coming from the compiler (unless there's perhaps some funky caching going on at some level).

@LaughingJohn are you still having this issue on the latest VS 2022 Preview?

[NTaylorMullen]

Seems like its fine in CLI but not in VS. Would this not fall under the tooling umbrella? @NTaylorMullen

If things are building ok but not in VS then the question becomes is the design time code that's being generated the issue OR are there lingering diagnostics from VS? My bet is it's the prior but we'd need clarification 😄

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.