Aspnetcore: Compilation error when one-way binding an attribute value to a c# string.

[stavroskasidis]

Title

Compilation error when one-way binding an attribute value to a c# string.

Minimal repro steps

1. Create a new Blazor app
2. Open Index.cshtml and add a private string Test; member in a @functions code block
3. Add a public string InputText {get; set;} prop in the @functions code block
4. Add the following input in the html code <input @bind(InputText) class="@Test" />
5. Try to build the project

Expected result

Code should compile

Actual result

The following error is produced

Error   CS1503  Argument 2: cannot convert from 'string' to 'Microsoft.AspNetCore.Blazor.RenderTree.RenderTreeFrame'    WebApplication1.Client  E:\Desktop\WebApplication1\WebApplication1\WebApplication1.Client\obj\Debug\netstandard2.0\Pages\Index.g.cs 42  Active

[aguacongas]

Did you try without double quotes ? <input @bind(InputText) class=@Test />

[agriffard]

I already encountered this compilation error when I use both a @bind() to a property and some Razor code in the same input.

If you put @bind(InputText) at the end, it works.
<input class="@Test" @bind(InputText) />

It is a workaround but I don't know why the compilation returns this message.

[SteveSandersonMS]

Thanks for letting us know. I believe this issue will no longer be applicable when we merge aspnet/Blazor#406. I'll close this since it's not applicable to do anything about it when it's about to disappear.

But if you notice any other condition where this can be triggered (without using @bind), please let us know!

[SteveSandersonMS]

@rynowak If you think I'm wrong about this please reopen!

[miroslavp]

I get the same error message with @onclick() .

The error message appears for code like this
<a @onclick(() => DoSomething()) href='@(SomeProperty)'></a>
but if I switch the places of @onclick() and href like this
<a href='@(SomeProperty)' @onclick(() => DoSomething()) ></a>
then the error goes away

Don't know how to reopen this bug

[SteveSandersonMS]

OK thanks @miroslavp! Reopening.

Again I think this issue will disappear when we remove @onclick(...) and replace it with onclick=..., but we should keep this issue open until we know for sure.

[rynowak]

This should be fixed in 0.2 with the new event handler feature.